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ABSTBACT 

This  work  describes  the  logical  design  of  a  proposed  deci- 
sion support  system  for  use  by  the  National  Communications 
System  in  forecasting  technology,  prices  and  costs.  it  is 
general  in  nature  and  only  includes  those  forecasting  models 
which  are  suitable  fcr  computer  implementation.  Because  it 
is  a  logical  design  it  can  be  coded  and  applied  in  many 
different  hardware  and/or  software  configurations. 
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I-  IH2RC) PACTION 

The  design  and  construction  of  software  for  a  modern 
information  system  is  a  rigorous  process  which  can  be 
described  in  a  life  cycle  which  consists  of  the  following 
steps: 

1.  Feasibility  -  Defining  the  basic  approach  and  general 
scope  of  a  software  project,  with  particular  emphasis 
on  determining  the  practicality  of  such  a  project 
over  its  entire  life  span. 

2.  Requirements  -  Specifying  the  required  functions, 
interfaces  and  actual  performance  of  the  software 
system,  including  operational  constraints. 

3.  Design  -  Defining  data  flow,  algorithms,  data  repre- 
sentations and  control  structures.  Identifying  and 
specifying  modules.  Usually  entails  at  least  two 
iterations  of  refinement. 

4.  Coding  -  Translating  the  design  into  a  programming 
language.   Includes  testing  of  individual  components. 

5.  Integration  -  Individual  system  components  are  inte- 
grated into  the  final  system  configuration. 

6.  Inplementation  -  Installation  of  the  software  product 
with  the  host  hardware  system,  to  include  testing. 

7.  Maintenance  -  All  subsequent  alterations,  modifica- 
tions and  improvements  made  to  the  complete  system. 

This  work  is  an  attempt  to  define  a  logical  software 
design,  based  on  general  system  requirements,  which  can  be 
"fine-tuned"  by  rigorous  specification  and  ultimately  used 
as  the  foundation  for  the  physical  implementation  of  a  deci- 
sion support  system  (ESS) .  As  such,  it  does  not  strictly 
follow  the  prescrib€d  conventional  software  development 
process.    It  is,   rather,   a   hybrid  approach  at  addressing 


several  of  the  traditional  phases  of  the  life  cycle:  feasi- 
bility, requirements  and  (logical)  design.  It  is  purposely 
of  such  a  general  nature  in  order  to  facilitate  speciiic 
system  requirements  and  ultimate  performance  of  the  entire 
software  development  life  cycle. 

One  of  the  underlying  design  principles  upon  which  this 
effort  is  based  is  that  of  software  generality.  An  auto- 
mated system  to  forecast  telecommunications  technology, 
prices  and  costs  should  be  designed  in  such  a  manner  as  to 
allow  for  maximum  utility  within  the  proposed  scope  of 
application.  This  particular  DSS  logical  design  enables  the 
NCS  manager  to  model  a  wide  variety  of  technology,  price  and 
cost  situations  without  the  associated  overhead  imposed  by 
multiple  application-specific  systems. 

The  Manager  of  the  National  Communications  System  (NCS) 
has  been  tasked  by  the  National  Security  Telecommunications 
Policy  of  3  August  1983  with  i nplementing  this  policy  under 
the  direction  and  with  the  consultation  of  the  Policy 
Steering  Group.  As  part  of  this  task,  the  Manager  must: 

1.  Ensure  the  development,  in  conjunction  with  the  NCS 
operating  agencies,  of  plans  to  fulfill  the  princi- 
ples and  objectives  stated  in  this  directive, 
including  an  overall  telecommunications  architecture 
and  timetable. 

2.  Develop,  for  review  by  the  Steering  Group,  overall 
budget  profiles  regarding  approved  initiatives  and 
related  activities. 

3.  Prepare  annually,  or  as  otherwise  directed,  a  written 
report  to  the  Steering  Group  on  the  progress  of 
approved  initiatives,  including  an  assessment  of  the 
resources  that  will  be  required  to  attain  the  objec- 
tives of  this  directive  [Ref.  1 ]. 

For  a  manager  to  make  effective  decisions  and  to  prepare 
effective  and  tittely  plans,   a  certain  amount  and  guality  of 
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information  has  to  be  available.  Martino  [Ref.  2]  states, 
"One  of  the  best-kept  secrets  of  the  planning  profession  is 
that  planning  has  nothing  to  do  with  actions  to  be  tak€n  in 
the  future.  Instead,  planning  deals  with  actions  to  be 
taken  in  the  present." 

The  information  reguired  for  planning  into  the  future 
partly  consists  of  estimates  as  to  what  the  future  holds. 
The  NCS  must  have  estimates  of  what  technologies  will  be 
available  at  a  later  time  and  what  the  cost  and  price  of 
that  technology  will  be.  A  decision  support  system  system 
which  utilizes  forecasting  techniques  and  models  can  be  used 
to  derive  accurate  estimates  and  aid  NCS  managers  in  making 
decisions  based  upon  these  estimates.  Forecasts  of  tech- 
nology are  useful  because  a  technological  change  can: 

1.  Provide  new  methods  of  achieving  objectives. 

2.  Render  certain   means  of   achieving  objectives   obso- 
lete. 

3.  Render  certain  objectives  obsolete. 

The  necessity  to  track  technology  growth  is  particularly 
important  once  it  has  been  identified  as  a  reeded  tech- 
nology. Isenson  [Bef.  3]  found  through  his  investigations  of 
Project  Hindsight  that  a  real  need  results  in  accelerated 
technological  growth.  The  greater  the  rate  of  the  growth  of 
a  technology,  the  more  it  can  influence  previously  made 
plans. 

This  paper  will  develop  a  decision  support  system  to 
forecast  technology,  prices,  and  costs  for  use  by  the 
National  Communications  System.  The  next  chapter  is  an 
overview  of  the  NCS.  Chapter  III  introduces  the  concept  of 
forecasting  and  forecasting  models,  with  a  discussion  on  how 
they  may  effectively  be  utilized  by  a  government  agency  such 
as  the  NCS.  The  actual  logical  design  for  the  decision 
support  system  will  then  be  developed  and  the  methods 
utilized  in  its  design  are  discussed.    The  conclusions  will 
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describe  why  the  particular  forecasting  models  i nplemented 
in  the  DSS  were  selected  and  also  dis<  ,s  possible  strat- 
egies for  i nplementation  of  the  DSS. 
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II.  THE  NATIONAL  COMMUNICATIONS  sysjjh 

A.   OVERVIEW 

The  National  Communications  System  was  formed  en  21 
August  1563  as  a  result  of  a  recommendation  by  the  National 
Security  Council  that  the  Executive  Office  move  to  identify 
and  coordinate  the  communications  needs  of  the  Federal 
Government.  Originally  envisioned  as  a  means  to  integrate 
the  many  systems  fcund  throughout  the  government,  the 
general  mission  of  the  NCS  continues  to  be  to  ensure  the 
surviveatility  of  communications  during  and  subsequent  to 
any  national  emergency.  In  order  to  accomplish  this  mission 
the  NCS  is  organized  not  as  a  homogenous,  separate  entity; 
rather,  it  is  an  arrangement  of  heterogeneous  telecommunica- 
tions systems  which  are  provided  by  their  sponsor  Federal 
agencies.  In  its  early  years  of  existence  the  NCS  was 
comprised  costly  of  General  Services  Administration  (GSA) 
and  Department  of  Defense  (DOD)  assets.  Today,  however, 
virtually  every  major  Federal  agency  is  a  participating 
member  of  the  NCS. 

The  physical  components  of  Federal  telecommunications 
systems  and  networks  included  under  the  NCS  may  be  described 
as  the  following: 

1.  Automatic  telephone  route  control  switching  facili- 
ties and  associated  first  level  user  switching  facil- 
ities. 

2.  Telephone  and  digital  data  switching  facilities  and 
primary  common  user  communications  centers. 

3.  Special  purpose  local  delivery  message  switching  and 
exchange  facilities. 
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4.  Fixed  route  government  owned  or  leased  transmission 
facilities  under  exclusive  control  of  a  government 
agency. 

5.  Government  owned  or  leased  radio  systems. 

6.  Technical  control  facilities  which  are  under  exclu- 
sive control  of  a  government  agency. 

7.  Other  services  provided  by  a  common  or  specialized 
carrier  on  a  continuing  basis,  via  commercial  facili- 
ties not  designated  for  exclusive  government  use. 
These  services,  like  exclusive  use  services,  will 
still  be  assigned  an  appropriate  restoration  priority 
in  the  event  cf  national  emergency  or  other  disrup- 
tion of  the  service.   [Ref.  4] 

Most  NCS  operating  component  systems  are  long-haul, 
trunk,  point-to-point  systems.  They  are  planned,  operated 
and  funded  by  their  sponsor  agencies  to  fulfill  a  specific 
peacetime  need.  The  current  NCS  management  doctrine  is  to 
provide  joint  central  planning,  standardization  and  program- 
ming. The  long  range  goal  is  to  ensure  progressive,  system- 
atic improvements  existing  systems  in  order  to  allow 
efficient  and  effective  transition  from  peacetime  to  emer- 
gency conditions. 

B.   NCS  POLICY 

As  the  number  of  NCS  operating  components  has  grown  over 
the  years,  so  also  have  the  organizational  responsibilities 
and  system  complexities.  In  order  to  clarify  and  define  the 
NCS  goals  and  objectives,  the  National  Security  Council 
(NSC)  established  in  1979  the  National  Security 
Telecommunications  Policy.  This  policy  directed  the  NCS  to 
ensure  telecommunications  assets  provide  for: 

1.  Emergency  communications  between  the  National  Command 
Authority  and  appropriate  forces  to  support  retalia- 
tory action  in  the  event  of  enemy  nuclear  attack. 
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2.  Military  operational  communications  for  both  general 
and  nuclear  conflicts. 

3.  Communications  in  support  of  military  mobilization. 

4.  Communications  to  ensure  government  continuity  in  the 
event  of  nuclear  or  natural  disaster,  and  recovery 
from  the  same.   [Ref.  5] 

In  August  1983  the  national  telecommunications  policy 
was  further  defined.  The  new  policy  addresses  the  vulner- 
ability of  existing  NCS  systems  to  nuclear  attack  and 
directs  enhancements  and  improvements  (i.e.,  switches  and 
control  centers)  be  physically  located  away  from  likely 
nuclear  target  areas  and,  whenever  feasible,  existing  system 
components  be  hardened.   [Ref.  1] 

Actual  policy  guidance  for  the  NCS  in  the  areas  of  tele- 
communications planning  and  development  is  fragmented  and 
originates  from  multiple  sources  at  the  Executive  Office 
level.  For  example,  the  Office  of  Science  and  Technology 
Policy  (CSTP)  is  tasked  with  the  responsibility  for  the 
collection,  recording  and  evaluation  of  existing  telecommu- 
nications facilities  and  the  development  of  profile  informa- 
tion detailing  the  residual  capabilities  of  these  systems 
and  networks  under  various  extraordinary  conditions, 
including  nuclear  and  other  national  emergencies  [Ref.  6]. 
Such  infcrmation  is  used  by  the  NCS  in  the  conduct  of  resto- 
ration and  allocation  activities,  resources  evaluation, 
damage  assessment,  reguirements  evaluation,  and  priority 
determination.  The  OSTP  facilities  status  evaluation 
provides  the  NCS  raw  data  pertaining  to  system  gross  opera- 
tional capabilities  in  terms  of  (1)  link/trunk  capability, 
(2)  call  demand/acceptance  capability  of  voice  switching 
systems,  (3)  message  processing  capability  of  record  traffic 
switching  systems,  (4)  user/subscriber  access  capability  of 
voice  and  record  switching  systems,  and  (5)  residual  major 
system  access  concentraters.     This  data  can  and   should  be 
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utilized  by  the  NCS  to  ensure  Federal  telecommunications 
systems,  derived  from  common  carrier  networks,  are  intercon- 
nected and  capable  of  interoperation  to  the  maximum  extent 
possible. 

C.   PBOCUBEHEHT  OF  SFBVICES 

More  than  95%  of  the  communication  services  utilized  by 
the  Federal  government  and  its  agencies  within  the  conti- 
nental United  States  are  provided  by  common  user  systems 
leased  from  and  operated  by  the  major  common  and  specialized 
commercial  carriers  (the  vast  majority  are  leased  from  AT&T 
long  Lines  and  associated  Bell  operating  or  interconnect 
companies)  [Ref.  7].  "Common"  user  systems  means  that  the 
physical  facilities  from  which  the  government  services  are 
derived  are  usually  also  common  to  public  message  services 
with  provisions  made  to  segregate  the  two  services.  Close 
and  continual  coordination  between  the  NCS  and  the  private 
sector  telecommunications  industry  is  facilitated  by  the 
Federal  Communications  Commission  (FCC)  and  the  National 
Industry  Advisory  Committee  (NIAC) .  During  wartime  or  other 
national  emergency  tte  authority  to  requisition  and  contract 
for  supplies  and  equipment,  and  to  restore,  expand,  repair 
and  construct  telecommunications  systems  is  delegated  to  the 
FCC.  However,  the  NCS  retains  overall  responsibility  for 
integrating  all  government  communications.  In  order  to 
perform  its  emergency  functions,  the  FCC  relies  heavily  upon 
the  NCS  Telecommunications  Emergency  Management  System 
(NTEMS)  . 

Peacetime  procurement  responsibility  is  centralized 
also,  but  divided  between  GSA  for  civil  agencies  and  the 
Defense  Ccmmunicaticns  Agency  (DCA)  for  DOD  systems. 
Certain  civil  agencies  and  components  have  been  authorized 
independent  authority   to  procure   directly  from   common  and 
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specialized  carriers  where  it  has  been  determined  to  be  mere 
convenient  for  the  government.  Such  exceptions  to  the  rule 
are  rare,  however,  primarily  due  to  the  paramount  necessity 
to  ensure  mutual  support  and  interoperability  among  the 
various  systems. 
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III.  OSE  OF  FCBECASTING  MODELS  IN  GOVERNMENT 

A.   CCHCEPTS 

The  general  concept  of  cost  and  price  projection  is  an 
integral  issue  associated  with  the  acquisition  of  major 
systems,  commercial  products  and  industrial  services  by 
agencies  of  the  federal  government.  This  concept  normally 
is  addressed  during  the  rigorous  process  known  as  economic 
analysis,  the  outcome  of  which  is  a  major  factor  either  in 
the  selection  of  a  choice  between  two  or  more  alternatives, 
or  in  assessing  the  economic  consequences  of  a  choice 
already  made  between  alternatives.  Unfortunately,  the 
literature  pertaining  to  economic  analysis  includes  rather 
generalized  and  imprecise  guidance  for  the  conduct  of  cost/ 
price  estimation,  key  elements  of  the  process.  In  practice, 
costing  and  pricing  within  the  federal  government  varies 
widely  from  agency  to  agency,  and,  even  within  agencies  there 
may  be  variety,  dependent  upon  the  type  of  product  or 
service  teing  acquired  [Ref.  8].  The  use  of  technology, 
price  and  cost  forecasting  models  is  one  method  available  to 
complement  and  enhance  an  agency's  established  employment  of 
economic  analysis  and  estimation  in  the  acquisition  life 
cycle. 

Regardless  of  the  scope  of  the  project  or  program 
involved,  the  acquisition  process  can  be  viewed  as  a  logical 
progression  of  iterative  reviews,  determinations  and  evalua- 
tions to  reconcile  periodic  adjustments  to  program  objec- 
tives and  requirements  or  resource  availability.  This 
process  overlaps  the  traditional  functions  of  planning, 
budgeting,  contracting  and  contract  administration,  each  of 
which   can   be   examined   as    an   area   of   specialization. 
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Historically,  federal  departments  and  agencies  have  utilized 
separate  estimation  and  analysis  units  within  each  stage  of 
the  acquisition  process.  In  addition,  each  unit  has  tended 
to  utilize  a  unique  costing  and  pricing  technique  for  each 
of  the  functional  specialties.  Furthermore,  as  each  esti- 
mate and  analysis  is  forwarded  through  the  organizational 
hierarchy,  policy  reviews  and  revisions  take  place. 
Although  some  agencies  utilize  a  centralized  cost/price 
estimation  and  analysis  activity,  they  are  the  exception  to 
the  rule.  The  normal  process  entails  redundancy  of  effort 
and,  all  to  often,  results  in  poor  cost  and  price  infcrma- 
tion.  Certainly  it  is  given  that  the  adequacy  of  data  is  a 
major  factor  in  the  quality  of  cost  and  price  estimates  and 
analyses,  but  the  importance  of  the  overall  methodology 
utilized  must  not  be  discounted.  This  is  the  case  particu- 
larly for  estimates  and  analyses  involving  new  technology 
and  major  systems. 

The  traditional  acquisition  costing/pricing  process  can 
be  significantly  enhanced  by  use  of  forecasting  techniques 
and  methods.  Forecasting  is  a  process  whose  objective  is  to 
predict  future  events  or  conditions  under  an  assumed  set  of 
circumstances.  The  most  common  applications  of  forecasting 
involve  the  use  of  estimating  models  to  predict  quantitative 
values  of  certain  variables  outside  the  sample  of  data  actu- 
ally observed.  In  the  case  of  cost  and  price  forecasts, 
these  values  would  mcst  likely  assume  a  probability  distri- 
bution rather  than  a  point  forecast.  Technology  forecasting 
looks  more  toward  the  time  period  by  which  certain  parame- 
ters of  a  given  technology  will  be  achieved.  An  example  of 
this  would  be  to  forecast  the  year  in  which  90%  of  telecom- 
munications common  carriers  will  be  using  digital  voice 
circuits  rather  than  analog  circuits. 

The  forecasting  process,  like  the  product  or  service  for 
which  the  forecast  is  made,   can   be  described  in  terms  of  a 


19 


life  cycle.  The  icrecaster  begins  the  process  by  identi- 
fying facts  and  other  data  about  past  trends  and  previous 
forecasts  relating  to  the  problem  under  consideration. 
Particular  attention  is  given  to  determining  the  cause  of 
variances  between  previous  forecasts  and  actual  system 
behavior.  The  forecaster  must  next  determine  and  organize 
future  parameters  of  the  decision  problem.  A  suitable  model 
which  describes  the  problem  space  is  then  constructed,  along 
with  a  method  and  measure  of  accuracy  and  reliability. 
During  the  course  of  the  project,  periodic  samples  are  taken 
to  compare  the  forecast  with  actual  behavior,  documenting 
variances  as  they  occur.  Finally,  the  forecast  is  revised 
as  necessary.   [Ref.  2] 

A  forecast  is  only  as  accurate  as  its  model,  and  a  model 
is  only  as  accurate  as  its  data  sources.  Moreover,  the 
model  used  represents  a  compromise  between  reality  and 
manageability.  It  must  identify  essential  factors  while 
disregarding  non-critical  ones.  A  good  model  specifies 
interrelationships  among  parts  of  the  system  such  that  it  is 
reasonably  detailed  and  explicit  to  ensure  the  model 
adequately  describes  the  real-world  system.  However,  it 
must  also  specify  them  in  such  a  way  that  it  is  understand- 
able so  that  proper  analysis  and  conclusions  regarding  the 
real-world  system  can  be  made. 

B.   PRICE/COST  FORECASTING  MODELS 

This  work  is  not  an  attempt  to  survey  the  entire  field 
of  available  forecasting  models.  The  focus  will  te  on  the 
most  common  type  of  parametric  model,  the  algebraic  model, 
which  is  particularly  well  suited  to  the  NCS  application 
because  of  the  ease  with  which  it  may  be  expanded  and  modi- 
fied. The  algebraic  model  typically  consists  of  several 
equations,  each  with  a  separate  meaning  and  role.   The  model 
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determines  values  of  certair  endogenous  variables,  the 
jointly  dependent  variables  which  are  simultaneously  solved 
by  the  relations  of  the  model.  Independent  exogenous  vari- 
ables are  determined  outside  the  system  but  influence  it  by 
affecting  the  values  of  the  endogenous  variables.  They 
affect  the  system  but  are  not  in  turn  affected  by  it.  An 
econometric  model  is  an  algebraic  model  that  typically 
includes  one  or  more  random  variables  (disturbance  terms) 
and  represents  a  system  by  a  set  of  stochastic  relations 
among  the  variables  cf  the  system-  Such  a  model  generally 
specifies  the  probability  distribution  of  each  endogenous 
variable,  given  the  values  taken  by  all  exogenous  variables 
and  given  the  values  of  all  parameters  of  the  model. 
[Bef.  9] 

A  cost  model  is  used  to  predict  the  anticipated  costs 
likely  to  be  incurred  in  a  project.  Like  other  models,  when 
a  cost  model  equation  or  system  of  equations  is  derived  from 
statistical  analysis  cf  a  sample  of  past  projects,  an  asso- 
ciated factor  is  a  degree  of  imprecision  or  uncertainty. 
The  validity  of  the  irodel  is  a  function  of  how  widely  the 
data  are  scattered  around  the  prediction  line  or  curve. 
Cost  models  must  generally  be  individually  structured  to 
best  meet  the  purpose  for  which  they  are  intended  (Table  1) . 
If  the  forecast  is  meant  to  aid  in  the  choice  between  alter- 
natives, the  differential  life  cycle  cost  model  would  be 
used.  Such  a  model  would  compare  the  differential  costs 
associated  with  the  alternative  systems.  Detailed  compar- 
ison between  the  alternatives  would  be  provided  by  summing 
the  differential  costs  identified  with  the  applicable  cost 
elements  chosen.  Conversely,  a  cost  model  based  upcn  total 
life  cycle  cost  would  concentrate  on  applicable  cost 
elements  over  the  projected  life  expectancy  of  a  particular 
equipment  or  system.  The  model  builder  would  identify  the 
cost  categories  and  associated  cost   elements  to  be  utilized 
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TABLE  1 
Life  Cycle  Cost  Models 

Total  Life  Cycle  Cost  Model 

Associates  all  applicable  cost  elements  over  the  life- 
time cf  a  system. 

Differential  Life  Cycle  Cost  Model 

Compares  differential   costs  between  two  similar  cost 
elements  of  two  different  systems. 


as   model  parameters.    Table  2   is  an   explanation  of   the 
conventional  majcr  cost  categories. 

C.   TECBHOLOGY  FORECASTING  MODELS 

Technology  forecasting  models  are  similar  to  price/cost 
models  in  that  the  primary  determinant  of  the  quality  of  the 
forecast  is  in  the  variables  which  are  brought  into  the 
model  and  how  they  are  weighted  in  relation  to  one  another. 
Once  this  has  been  accomplished,  different  techniques  can  be 
utilized  to  fit  a  curve  to  the  historic  data  in  order  to 
project  the  value  of  the  technology  parameter  at  a  future 
time.  The  model  is  highly  dependent  upon  the  core  assump- 
tions made  about  the  environment  which  is  being  forecast. 
In  particular  is  the  assumption  regarding  the  existence  of 
upper  limits  (or  lower  limits  in  the  case  of  time  reduc- 
tions) on  the  capabilities  of  the  technology  being  modeled. 
An  example  of  an  upper  limit  assumption  would  be  the  speed 
cf  light  for  spacecraft  velocities.  Other  than  extrapo- 
lating trends  into  the  future  by  curve  fitting,  technology 
forecasting  can  sample  the  amount  of  literature  circulating 
in  an  area  of  technolcgy.   By  monitoring  the  growth  (or  lack 
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TABLE  2 
Major  Cost  Categories 

E^search  and  Development  Costs 

All  costs  associated  with  the  research,  development, 
test  and  evaluation  of  the  equipment/system.  Normally 
these  costs  are  incurred  during  concept  initiation, 
validation  and  full  scale  development. 

Nonrecurring,  Investment  Costs 

All  costs  incurred  one  time  beyond  the  program  devel- 
opment phase  and  during  the  program  production  phase. 
These  costs  can  occur  if  there  is  a  change  in  design, 
contractor  or  manufacturing  process. 

R§£i3I£iS.£  Investment  Costs 

All  production  costs  that  recur  with  each  unit 
produced. 

Q£££atinc[  §^  Maintenance  Costs 

All  costs  associated  with  personnel,  material,  facili- 
ties and  other  costs  required  to  operate,  maintain  and 
support  an  equipment/system  during  its  useful  life- 
time. 


of  growth)  in  an  area,  it  can  be  estimated  that  the 
increased  communications  among  researchers  will  result  in  an 
exponential  growth  of  knowledge,  likely  to  result  in  a 
breakthrough  or  an  advancement  of  the  technology  teing 
studied.  This  area  of  forecasting  can  be  directly  influ- 
enced by  infusion  of  government  resources  into  research 
[Ref.  3].  If  a  certain  level  of  a  parameter  of  a  technology 
is  desired  by  a  certain  date,  the  amount  of  research  and 
development  necessary  now  can  be  estimated.  The  recent 
Presidential  initiative  regarding  the  so-called  "Star  Wars" 
technology  is  an  example  of  this  technique. 
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D.   SUMMARY 

Although  forecasting  models  are  well  suited  for  adapta- 
tion to  automated  systems,  they  are  not  without  their  poten- 
tial problems.  Depending  upon  the  real-world  project  and 
model  application,  forecasters  may  find  a  limited  number  of 
relevant  statistical  procedures  available.  Once 
constructed,  models  may  quickly  become  obsolete  by  the  rapid 
growth  of  the  technology  being  forecast.  Hence,  effort  must 
be  directed  toward  a  method  for  adapting  the  model  for  tech- 
nological advance  even  during  periods  of  rapid  growth.  The 
forecaster  may  be  confronted  with  the  mathematical  problem 
of  solving  k  equations  in  n  unknowns  (k  <  n) .  A  host  of 
problems  involving  accuracy  of  the  model  may  be  caused  by 
omission  of  a  relevant  exogenous  variable,  disregarding  a 
qualitative  change  in  one  of  the  variables,  inclusion  of  an 
irrelevant  variable,  incorrect  definition  of  a  variable,  and 
in  the  case  of  econometric  models,  incorrect  specification 
of  the  manner  in  which  the  stochastic  disturbance  term 
enters  the  equation. 

The  effects  of  divestiture  and  deregulation  of  the  tele- 
communications industry  are  major  contributing  reasons  for 
the  National  Communications  System  to  consider  use  of  fore- 
casting techniques.  As  the  MCS  continues  to  grow  in  size, 
scope  and  complexity  of  participating  systems  (for  example, 
the  conversion  from  analog  to  digital  voice  circuits) ,  even 
more  powerful  tools  will  be  required  to  exert  effective 
managerial  control  over  further  development.  Accordingly, 
the  objective  of  forecasting  technology,  cost  and  price  is 
not  to  provide  a  managerial  decision,  but  to  derive  further 
inputs  to  the  managerial  decision-making  process.  Numerous 
potential  applications  exist  within  the  traditional 
Planning,  Programming  and  Budgeting  System  (PPBS)  and  acqui- 
sition cycles.     For  example,    it  can  be   used  in   lieu  of 


24 


conventional  cost-estimating  during  the  cost/benefit  anal- 
ysis (concept  development  of  the  acquisition  cycle) .  It  can 
be  used  to  evaluate  alternatives  during  strategic  planning. 
It  can  be  utilized  during  periodic  revisions  of  the 
Five- Year  Defense  Plan  (FYDP) ,  or  similar  intermediate-term 
plan  for  GSA-procured  systems.  As  a  general  rule,  an  auto- 
mated forecasting  system  would  be  ideal  for  use  whenever 
traditional  economic/technological  analysis  is  too  elabo- 
rate, too  time-consuming  and/or  too  expensive  for  the  scope 
of    the    particular   problem   or   project    at    hand. 
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IV.  PBELIMINABY  DATA  DICTIONARY  DESIGN 

In  order  to  develop  a  database  for  a  decision  support 
system  it  is  necessary  to  look  at  the  overall  requirements 
for  designing  such  a  system  with  special  emphasis  on  the 
data  which  will  be  utilized.  The  DSS  architecture  presented 
by  Dolk  [ Eef .  10]  consists  of  four  major  components:  (1) 
dialog,  (2)  model  base,  (3)  knowledge  base,  and  (4)  data- 
base. The  dialog  is  the  primary  driver  of  the  system.  It 
is  the  interface  with  the  user;  therefore,  the  dialog  is 
dependent  upon  what  outputs  the  decision-maker  wants  from 
the  DSS  and  what  inputs  can  be  to  provided  to  get  that 
output.  The  model  base  will  provide  the  basic  algorithms  of 
the  system  models  as  well  as  the  value  abstractions  of  the 
coefficients  for  the  variables  to  be  utilized  by  the  model 
algorithms.  The  knowledge  base  contains  a  set  of  heuristics 
which  determine  what  type  model  or  combination  of  models 
will  be  processed  for  a  given  circumstance  provided  by  the 
user.  The  database  will  contain  the  structure  and  values  of 
all  data  in  the  DSS  which  is  subject  to  modification  and/or 
addition  by  the  user  without  modifying  the  program  itself. 
The  data  utilized  by  the  dialog,  model  base,  and  knowledge 
base  determine  what  will  be  in  the  database,  and  will  there- 
fore be  examined  briefly  in  turn. 

A.   DIALOG 

The  "rule  of  thumb"  in  DSS  design  (or  in  any  systems 
analysis  for  that  matter)  is  to  first  determine  what  will  be 
the  outputs  and  inputs  to  the  system.  Because  all  interface 
with  the  user  is  through  the  dialog,  this  is  paramount  to 
determining  what  the  dialog  is  to  be.   The  prime  question  to 
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be  asked  is,  "What  does  the  user  need  in  a  forecast  of  tech- 
nology?" The  answer  to  that  question  for  the  purposes  of 
this  DSS  is  that  the  decision-maker  wants  the  DSS  to  provide 
a  presentation  of  trends  for  a  given  parameter  in  an  area  of 
a  technology,  given  a  set  of  assumptions  and  optionally 
given  a  set  of  parameters  from  other  areas  which  may  impact 
upon  the  technology,  including  the  degree  to  which  they  do 
so. 

The  following  are  outputs  required  from  the  dialog: 

1.  A  list  of  the  assumptions  used  in  generating  the 
forecast. 

2.  The  type  of  model (s)  being  utilized. 

3.  A  graphical  presentation  of  historical  data  versus 
time  extrapolated  by  one  of  the  models  to  get  an 
indication  of  a  trend,  whether  increasing,  decreasing 
or  steady  and  which  includes  the  scale  used,  whether 
linear  or  logarithmic. 

4.  The  source  of  the  data  on  the  graph  and  its  type, 
whether  subjective,  objective  or  estimate. 

5.  A  comparison  of  this  forecast  with  previous  fore- 
casts. 

6.  Which  parameters  of  the  model  are  exogenous  or 
endogenous  and  of  these,  which  can  be  influenced  by 
the  decision-maker. 

The  following  inputs  to  the  dialog  are  required: 

1 .  An  ability  to  create  data  with  these  characteristics: 
identifiers  for  name,  type  of  factor  it  is,  source  of 
the  data,  date  of  the  data  entry  and  date  of  the  data 
otservation. 

2.  An  ability  to  alter  assumptions  and  parameters  in 
order  to  observe  any  changes  in  the  output.  This  can 
include  a  means  for  indicating  the  stochastic  nature 
of  some  of  the  variables.  For  example,  in  a  price/ 
cost   model  the   expected   future   interest  rates   of 
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treasury  bonds  may  be  estimated  as  a  triangular 
distribution  cf  the  interest  rate  around  a  most 
likely  value  for  the  interest  rate,  bounded  ty  an 
estimated  high  value  and  low  value  which  can  then  be 
iterated  through  the  model  as  a  Monte  Carlo  simula- 
tion. 

3.  An  ability   to  create   different  model  equations  for 
input  into  the  model  algorithm. 

4.  An  ability  to  override  the   knowledge  base  and  select 
a  specific  model  to  run. 

B.   MCDE1  BASE 

This  DSS  utilizes  two  primary  models.  The  first  of  these 
is  a  curve  fitting  model  which  regresses  a  straight  lire  on 
the  plots  of  five  different  functions  of  the  factor  or 
aggregate  model  score  to  forecast.  These  functions  are  a 
Fearl  crowth  function,  a  Gompertz  growth  function,  a  func- 
tion in  which  the  natural  logarithm  of  the  dependent  vari- 
able is  taken,  and  a  function  in  which  the  natural  logarithm 
of  the  dependent  variable  and  the  natural  logarithm  of  the 
independent  variable  are  calculated.  The  regression  which 
has  the  highest  correlation  factor  is  selected  for  use  in 
extrapolating  into  the  future.  This  method  of  forecasting 
has  teen  selected  due  to  its  simplicity  and  intuitive  under- 
standing of  the  process  by  a  manager.  The  second  model  in 
the  DSS  is  a  simple  cross  impact  analysis  model  developed  by 
Julius  Kane  [Ref.  2]. 

1  •   Scoring  Model 

A  scoring  model  will  take  different  factors  named  by 
the  decision-maker  and  combine  them  to  determine  an  aggre- 
gate score  (hence  the  name  scoring  model) .  This  is  accom- 
plished through   queries  directed  at   the  user   to  determine 
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the  relationships  among  the  factors.  Any  factors  which  are 
essentially  the  same  are  eliminated  so  that  only  one  factor 
will  represent  that  area  in  the  model.  Next  the  factors  are 
grouped  to  determine  whether  they  are  additive  or  multipli- 
cative, either  of  the  entire  model,  or  of  groups,  and  so  on. 
Care  must  fce  taken  in  choice  of  multiplicative  factors,  for 
if  the  value  of  the  factor  is  zero,  then  all  of  the  factors 
which  it  multiplies  are  then  zero.  Weights  are  now  assigned 
by  the  user  to  the  different  groups  or  individual  factors. 
Desirable  and  undesirable  factors  and  groups  are  separated 
with  the  desired  factors  being  in  the  numerator  and  unfavo- 
rable factors  being  placed  in  the  denominator.  This  is  the 
basic  model  equation  and  can  be  stored  as  such. 

The  user  must  identify  whether  the  data  is  subjec- 
tive or  objective.  If  subjective,  the  user  will  utilize  a 
standard  scale  of  zero  to  nine  in  selecting  the  value  for 
the  factor,  while  objective  data  will  be  examined  and  the 
mean  and  standard  deviation  for  each  factor's  data  being 
calculated.  The  mean  of  the  data  can  then  be  assigned  a 
value  of  the  user's  choice,  and  the  other  values  determined 
as  fractions  of  the  standard  deviation  to  range  from  a  low 
to  a  high  value  also  of  the  decision-maker's  choice. 

This  type  of  model  is  useful  in  comparing  different 
technologies  which  perform  similar  missions.  An  example 
drawn  from  telecommunications  technology  is  a  comparison  of 
satellite  communications  versus  landlines  versus  microwave 
links.  For  determicing  the  relative  vulnerability  of  each 
to  disaster  or  nuclear  attack,  a  subjective  factor  can  be 
utilized,  while  cost  of  mainterance  or  installation  will  be 
an  objective  factor. 

2  •   I^arl  and  Gomj^ertz  Curves 

These  two  curves  are  discussed  jointly  because  they 
are  essentially  the  same  functions,   differing  mainly  in  the 
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underlying  assumptions.  Both  curves  are  "S"  shaped  and  are 
extrapolated  by  first  straightening  out  the  curve  as  plotted 
by  the  factor  data.  This  is  accomplished  by  taking  the 
logarithm  of  the  curve,  once  for  the  Pearl  curve,  twice  for 
the  Gompertz  curve.  The  data  thus  transformed  has  a 
straight  line  regressed  on  it  to  obtain  the  values  for  the 
curve  functions.  The  eguation1  for  the  Pearl  curve 
(Eguation  4.1)    and  its  algebraic   transformation  (Eguation 

4.2)  utilize  In  a  as  the  constant  and  b  as  the  slope,  b 
taken  to  be  positive.  L  is  the  assumed  limitation  of  the 
technology  and  t  is  time  while  y   is  the  value  of  the  factor 

y  =  L/(1  +  a  *  (e  **  (-b  *  t)))  (4.1) 

Y  =  (L  -  y)/y  =  In  a  -  b  *  t  (4.2) 

under  consideration.    The  Gompertz  curve  eguation  (Eguation 

4.3)  and  its  algebraic  transformation  (Eguation  4.4)  utilize 
In  b   as  the  constant   and  k  as   the  slope.    The   other  two 

y  =  L  *  (e  **  (-b  *  (e  **  (-k  *  t)  )  ) )  (4.3) 

Y  =  In  (In  (L/y)  )  =  In  b  -  (k  *  t)  (4.4) 

variafcles  are  the  sane  as  before. 

The  different  assumptions  underlying  the  choice  of 
these  twc  curves  is  in  the  dynamics  of  the  technology  teing 
forecast.  If  the  previous  progress  in  implementation  or 
development  of  a  technology  will  influence  the  rate  of  the 
progress  of   the  technology,   then   a  Pearl  curve   should  be 


l1he   following  translations  describe  notations  which  may 
be  unfamiliar  to  the  reader: 

'*»  =  multiplication  operator 
t**i  =  exponentiation  operator 
'In'  =  natural  logarithm  function 
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used.  However  if  the  determining  factor  is  how  much  remains 
to  be  accomplished  before  the  assumed  limit  to  growth  of  the 
technology  is  reached,  then  the  Gompertz  curve  should  be 
utilized. 

An  example  of  the  use  of  the  Pearl  curve  is  a  fore- 
cast of  the  number  cf  households  which  have  access  to  a 
broadband  communicaticns  media.  The  factor  in  this  instance 
is  the  number  of  homes  with  cable  television  installed.  The 
maximuir  limit  ('L')  is  that  100%  of  households  which  have 
televisions  have  cable  installations.  A  Pearl  curve  is 
appropriate  because  the  technology  is  driven  by  the  degree 
of  acceptance  with  which  it  is  received  by  the  public. 

A  forecast  of  the  percentage  of  common  carrier  local 
distribution  systems  which  will  have  optical  fiber  as  the 
transmission  media  can  be  modeled  by  a  Gompertz  curve.  The 
limit  in  this  example  is  for  100%  of  existing  local  distri- 
bution systems  to  have  been  replaced  by  optical  fiber 
systems.  Since  this  substitution  is  influenced  more  by  the 
number  of  systems  remaining  to  be  upgraded  rather  than  by 
the  number  of  systems  which  have  already  been  implemented,  a 
Gompertz  curve  is  the  correct  growth  curve  for  the  forecast. 

3 .   Cross  Impact  Analysis 

This  is  a  simple  model  which  takes  a  factor  in  an 
area  cf  a  technology  and  determines  the  next  value  it  will 
have  as  a  result  of  the  impact  of  other  factors,  both  exoge- 
nous and  endogenous.  The  model  is  simple  in  that  only  the 
impact  of  a  single  variable  upon  another  variable  is  deter- 
mined at  a  time,  not  all  variables  at  once.  The  inputs  by 
the  decision-maker  are  purely  subjective  evaluations  of  what 
the  impacts  of  certain  chosen  variables  are  upon  the  factor 
being  evaluated,  plus  the  original  value  of  this  factor 
(subjectively  scaled  from  zero  to  one  in  increments  of 
0.00  1).    The  use  of  such  a  model  is  for  a  decision-maker  to 
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get  an  idea  of  the  results  of  varying  the  impacts  of  other 
factors  upon  a  factor.  Therefore,  it  is  necessary  for  the 
impacting  factors  to  be  defined  as  either  endogenous  or 
exogenous  variables  so  that  the  decision-maker  will  know 
which  variables  are  able  to  be  influenced.  An  example  of  an 
application  of  this  model  is  found  in  Chapter  VI. 

C.  KNOWLEDGE  BASE 

The  knowledge  base  of  this  particular  DSS  does  not  have 
anything  stored  in  the  database.  The  rules  for  determining 
which  models  tc  :un  are  within  the  algorithms  of  the  program 
itself.  The  only  impact  upon  the  data  dictionary  is  in  the 
identification  of  objects  passed  by  the  dialog  to  the  knowl- 
edge base.  This  would  consist  of  determining  whether  a 
request  for  a  model  run  is  for  more  than  one  specific  area 
of  a  technology,  which  would  activate  a  scoring  model  to 
arrive  at  a  conglomerate  representation  of  the  overall  tech- 
nology/  or  in  determining  whether  a  Pearl  or  Gompertz  curve 
is  to  be  utilized  in  extrapolation  of  the  data.  The  cross 
impact  model  will  be  invoked  when  the  user  specifically 
directs  that  it  be  run. 

D.  DEVELOPMENT  OF  THE  DATA  DICTIONARY 

The  technique  to  be  utilized  in  the  development  of  this 
ESS  is  drawn  from  the  works  of  Yourdon  [Ref.  11]  and  DeMarco 
[Ref.  12].  Their  methods  of  structured  analysis  and  design 
result  in  a  logical  flow  toward  a  complete  software  design 
without  the  large  amounts  of  paper  normally  associated  with 
a  software  design  project.  The  less  documentation  which  has 
to  be  changed  in  later  design  revisions  of  the  DSS,  the 
greater  the  possibility  that  the  documentation  will  be 
updated  to  reflect  changes  made  to  the  actual  software.  The 
essential  elements   of  the  DeMarco   and  Yourdon   methods  are 
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the  development  of  a  data  flow,  a  data  dictionary,  and  the 
process  descriptions.  In  order  to  develop  the  data  flow, 
the  composition  of  the  data  inputs  and  outputs  to  the  system 
have  to  he  described  in  the  data  dictionary.  The  data  flow 
will  only  show  the  flow  of  the  data  objects  through  the 
system,  while  the  process  descriptions  provide  information 
about  the  content  and  processing  of  the  data. 

The  data  objects  are  described  in  the  data  dictionary 
primarily  through  the  use  of  the  three  types  of  relations 
presented  by  Bohm  and  Jacopini  [Ref.  13].  These  are 
seguence,  selection  and  iteration.  Seguence  is  a  concatena- 
tion of  two  or  more  data  objects  and/or  data  elements 
together.  Selection  is  a  choice  between  two  or  more  data 
items.  Iteration  is  the  repetition  of  a  data  object,  or 
group  of  data  objects,  zero  or  more  times.  In  addition  to 
these  relations,  an  optional  relation  is  added  so  that  it  is 
possible  to  indicate  if  a  data  object  may  or  may  not  be  part 
of  a  larger  data  object.  For  this  data  dictionary  a  data 
element  is  considered  to  be  data  which  is  not  further  broken 
down  into  other  data  elements.  The  level  to  which  a  data 
element  is  broken  dcwn  is  left  to  the  user  and  the  data 
dictionary  designer.  A  data  object  may  be  Broken  down  into 
component  data  objects  and/or  data  elements.  Table  3 
explains  the  notation  utilized  in  this  data  dictionary. 

The  data  dictionary  for  the  DSS  is  developed  by 
analyzing  the  descriptions  of  the  dialog,  model  base  and 
knowledge  base  in  the  previous  sections.  This  will  result 
in  an  initial  look  at  how  data  objects  may  flow  through  the 
system.  Because  this  is  the  initial  version  of  the  data 
dictionary  it  is  inevitable  that  the  data  objects  will 
change,  be  added,  or  be  dropped  if  it  appears  during  further 
design  of  the  system  that  they  will  not  be  utilized  by  the 
system.  Usually  a  data  flow  technigue  is  utilized  in 
analyzing  an  existing  system  in  order  to  automate  it.    This 
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Data 

TABLE  3 
Dictionary  Notation 

Notation 

X  Consists  Of 

X 

= 

a  +  b 

data  objects  a  and  b 

X 

= 

[a|b] 

either  a  or  b 

X 

= 

{a} 

zero  or  more  occurances  of  a 

X 

= 

(a) 

optional  data  element  a 

X 

= 

y{a} 

y  or  more  occurances  of  a 

X 

= 

(a}z 

z  or  fewer  occurances  of  a 

X 

-" 

y  £a}z 

between  y  and  z  occurances  of  a 

. 

design  is  different  in  that  an  attempt  is  being  made  to 
design  a  system  which  does  not  yet  exist.  Therefore  the 
data  dictionary  depicted  in  Table  4  is  admittedly  of  a 
preliffinary  nature. 

With  the  use  of  this  data  dictionary  an  initial  data 
flow  can  be  constructed.  The  data  flow  will  be  expanded  tc 
different  levels  until  the  transformation  of  the  input  data 
to  the  output  data  is  fully  described.  Upon  the  completion 
of  the  expansion  of  the  data  flow  the  process  descriptions 
will  le  written.  These  descriptions  will  be  compared  with 
the  data  dictionary  in  order  to  determine  if  any  of  the  data 
is  not  utilized  or  if  there  is  data  which  must  be  added  to 
the  data  dictionary.  The  data  is  then  normalized  and  a  data 
structure  diagram  is  constructed.  With  the  addition  of  the 
format  in  which  the  data  will  actually  be  stored,  the  data 
dictionary  will  be  complete  and  serve  as  a  reference  docu- 
ment during  the  detailed  design  of  the  decision  support 
system. 
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TABLE  4 
Preliminary  Data  Dictionary 


ALGORITHM_NAME 

CHARACTERISTIC 

DATE 
DATE_CF_ENTRY 

DATE_CBSERVATION 

DISTRIBUTION 

ELEMENT 

ELEMENT_ANALYSIS 
ELEMENT_ENTRY 

ELEMENT_SOURCE 
EIEMENT_VALUE 

FACTOR 


♦Name  of  a  modeling  algorithm 
used  as  part  of  key  to 
identify  a  data  object  which 
contains  the  data  which  will 
be  used  by  a  model* 

[ "Exogenous" | "Endogenous"  ] 
'Identifies  whether  data  is 
controllable* 

"MM/ED/YY" 

DATE 

*Date  data  entered  into 

database* 

DATE 

*Date  data  for  ELEMENT  ENTBY 

observed  or  estimated* 

[ "Norm"! "Uni"l "Tri"  ] 
*How  stochastic  variable 
is  distributed* 

*Sut-area  within  a 
technology* 

[  "Historical" | "Estimate"  ] 

DATE  OF  OBSERVATION 
ELEFfE  NT"  SOURCE 
DATE  OF~ENTRY 
ELEM"ENT"VALUE 
ELEMENT~ANALYSIS 

♦Source   of   data    for 

ELEMENT_ENTRY* 

MOST    LIKELY    VALUE 
(HIGH    VALUE" 
LOW    VA"LUE 
DISTRIBUTION) 

FACTOR    IDENTIFIER 
FACTOR~TYPE 

(UNITS7 
CHARACTERISTIC 

{ELEMENT    ENTRY} 


I 
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- 
Table  H 

Preliminary 

Data  Dictionary  (cont'd) 

FACTOR_IDENTIFIER 

= 

TECHNOLOGY 
ELEMENT 

FACTOR_OPERATOR 

= 

GROUP_OPERATOR 

FAdOR_TYPE 

= 

[ "Subj"|  "Obj"  ] 

FACTOR_WEIGHT 

*Any  positive  integer  -  a 
subjective  evaluation  of 
the  factor  in  the  sub- 
group* 

GRCUP_IDENTIFIER 

— 

*A  unique  name  within  the 
data  object  to  identify 
a  grouping* 

GRCUP_LEVEL 

*An  integer  greater  than  0 
used  to  indicate  which  other 
groups  this  group  acts  on 
The  lower  number  groups  act 
on  all  groups  of  higher 
numter* 

GRCUP_0PERATOR 

= 

[ "Mult"|  "Add"  ] 

GRCUP_WEIGHT 

— 

*Any  real  number  -  a 
subjective  valuation  of  the 
group  in  the  model* 

GROUPS 

GROUP  IDENTIFIER 
GROUP-OPERATOR 
GROUP~WEIGHT 
GROUP-LEVEL 
{SUB  GROUP 
SUB  GROUP  WEIGHT 
SUB~GR0UP~0PERATOR} 

HIGH_VALUE 

*Any  real  number  greater 
than  or  egual  to  the 

ELEMENT  VALUE'S 
M0ST_LIRELY_ VALUE* 

IMPACT_FACTOR 

= 

*A  subjective  valae  -  a 
single  digit  0-9* 

IMPACTING_FACTOR 

= 

FACTOR_IDENTIFIER 

LIMITING_FACTOR 

FACTOR  IDENTIFIER 
FACTOR~TYPE 
(UNITST 

CHARACTERISTIC 
1  {ELEMENT  ENTRY}  1 
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Table  4 
Preliminary  Data  Dictionary  (cont'd) 


LOW  VALUE 


MODEL 


MODEL  IDENTIFIER 


MOST_IIKELY_VALUE 
SCALE_FOR_DATA 
SUB  GROUP 


SUB  GROUP  IDENTIFIER  = 


SUE_GRCUP_OPERATOR 
SUE_GROU?_WEIGHT 

TECHNOLOGY 
UNITS 


♦Any  real  number  less  than  or 
equal  to  the  ELEMENT  VALUE'S 
MOST_LIKELY_VALUE*   " 

ALGORITHM  NAME 
MODEL  IDENTIFIER 
GROUPS} 

'LIMITING  FACTOR) 
'IMPACTING  FACTOR 
IMPACT_FACTOR} 

♦Name  given  by  user  used 
along  with  ALGORITHM_NAME 
to  identify  the  data  object 
containing  the  data  to 
be  modeled* 

*Any  real  number* 

[ "Linear"! "Log"  ] 

SUB  GROUP  IDENTIFIER 

{SUE  GROUP 

SUB  CROUP  WEIGHT 

SUB~GR0UP~0PERATOR} 

{FACTOR   " 

FACTOR  OPERATOR 

FACTOR'WEIGHT] 

*A   recursive   definition 

Sub-groups    may   contain 

other    subgroups* 

*A   unigue   name   for   a   sub- 
group   within   the    group* 


=       GRCUP_OPERATOR 

=      *Any   positive    integer   -    a 
subjective   evaluation    of    the 
SUB    GROUP    in    the    GROUP    or 
SUB'GROUP* 

=   *Name  of  a  technological  area 
at  user's  discretion* 

=   *Units  of  measure  for 
ELEMENT  ENTRY'S* 
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7.  PROCESS  SPECIFICATIONS 

The  process  specifications  are  descriptions  of  each  of 
the  nodes  in  the  system  where  data  flows  are  transformed 
from  one  form  of  composition  into  another  composition.  A 
characteristic  of  these  specifications  is  that  each  should 
describe  an  underlying  policy  of  the  system,  specifying  what 
is  to  be  accomplished  rather  than  how  to  accomplish  it.  To 
do  this  they  are  written  in  a  form  known  as  Structured 
English.  Structured  English  is  a  form  of  English  in  which 
the  majority  of  nouns  used  will  come  from  the  data 
dictionary.  A  reserved  list  of  words  is  utilized  to  denote 
the  actions  within  the  process.  Examples  of  words  from  this 
list  are  those  words  which  use  the  three  techniques  of 
program  construction.  For  sequence  structures  statements 
within  a  program  should  follow  one  another.  To  show  decision 
the  usual  constructs  are  'If .. .then. .. else' ,  'If. ..then1,  or 
' If ..  .then. . .otherwise '.  For  multiple  decisions  some  varia- 
tion of  a  'Case1  structure  is  employed  (i.e.,  Case  of  This, 
Do  This,  Do  That,  Do  The  Other  Thing) .  Iterations  are 
expressed  as  ' Repeat ...  Until  some  condition  is  met1, 'While  a 
condition  is  present  do...1,  or  'For  a  certain  number  of 
times  do...'.  A  thorough  treatment  of  the  topic  is  provided 
in  [Ref.  12]. 

The  process  specifications  written  here  are  referred  to 
as  process  mini-specifications  or  'mini-specs',  due  tc  the 
fact  that  each  specification  is  unique  to  itself  and 
describes  a  smaller  system  contained  within  the  whole 
system,  each  having  its  specified  inputs  and  outputs.  To  the 
remainder  of  the  system  the  process  will  appear  to  be  a 
'black  box'  with  inputs  going  in  and  outputs  coming  out, 
somehow  transformed   by  the  process.     In  this   chapter  the 
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inputs  and  outputs  for  each  process  are  listed.  The  under- 
lying policy  of  each  process  is  provided  to  indicate  what 
the  process  is  to  do.  Due  to  the  length  of  the  mini-specs, 
they  have  been  placed  in  a  separate  appendix.  Prior  to  each 
mini-specification  the  inputs  and  outputs  along  with  their 
respective  sources  and  destinations  are  provided.  Following 
the  mini-specifications  are  the  McCabe  complexity  numbers  of 
the  processes,  and  a  description  of  the  basis  paths  of  the 
processes. 

A.   THE  MCCABE  COMPLEXITY  METRIC  IN  SOFTWARE  DESIGN 

The  McCabe  Cyclomatic  Complexity  Measure  was  first 
developed  for  testing  of  already  coded  modules.  McCabe's 
p  >er  [Ref.  14]  presents  the  idea  of  applying  a  complexity 
m  isure  in  the  design  phase  of  software  design.  Previously 
this  metric  had  only  been  applied  to  completed  code.  The 
reasoning  behind  application  of  this  metric  in  the  design 
phase  is  that  many  more  errors  occur  in  the  design  phase 
than  in  the  coding  phase.    This  fact  is  demonstrated  by  the 

TABLE  5 
Relative  Frequency  of  Design  and  Coding  Errors 

Source  Statements   Design  Errors  Coding  Errors 
Mc  lif ication         (No.)  (56)  {%) 

A  1253  73.6  26.4 

E  9880  73.7  26.3 

C  779  35.6  64. U 

E  9631  51.6  48.4 

E  4575  58.8  41.2 


data  in  Table  5  which  is  from  a  software  reliability  study 
conducted  at  TRW  of  the  percent  of  errors  introduced  in  a 
series  of  modifications  to  a  large  software  project  (100,000 
lines  of   code)   [Ref.  15]-     The  extension   of  the   McCabe 
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complexity  metric  to  the  design  testing  of  processes  will 
help  to  identify  logic  path  errors  and  will  provide  the 
number  of  basis  paths  through  a  process.  A  basis  path  is 
one  of  the  set  of  possible  independent  paths  from  the  entry 
point  of  the  process  to  the  exit  point  from  the  process. 
The  set  does  not  include  variations  from  the  independent 
paths  due  to  iterations  of  statements  along  the  path. 
Knowledge  of  these  paths  helps  to  determine  the  makeup  of 
the  test  data  to  be  utilized  later  in  testing  the  coded 
designs. 

The  primary  purpose  of  the  McCabe  Cyclomatic  Complexity 
measure  (henceforth  referred  to  as  "the  comp  exity  measure") 
is  to  limit  the  number  of  independent  paths  in  a  process. 
Yourdcn  and  Constantine  [Ref.  11]  present  the  idea  that  an 
acceptable  guideline  for  the  length  of  a  process  is  that  the 
Structured  English  syntax  or  decision  table  be  no  more  than 
one  page  in  length.  They  acknowledge  that  this  is  a  very 
general  guideline  but  that  it  should  be  utilized  in  addition 
to  ensuring  that  a  process  be  strongly  cohesive.  However,  as 
pointed  cut  by  McCabe,  a  50  line  process  with  25  selection 
statements  will  result  in  33.5  million  control  paths. 

In  order  to  determine  what  the  complexity  of  a  process 
..ould  be,  it  must  first  be  established  how  complex  a 
process  may  be  before  a  programmer  can  no  longer  effectively 
and  rapidly  understand  it.  Throughout  managerial,  psycholog- 
ical, and  software  engineering  literature  this  complexity 
limit  is  known  as  the  Hrair  limit.  As  applied  to  software 
design,  it  has  been  determined  to  be  seven  logical  events, 
plus  or  minus  two  logical  events  £Ref.  14]-  The  application 
of  this  limit  to  processes  is  that  the  number  of  basis  paths 
through  a  process  should  be  limited  to  seven.  Such  a  limit 
will  aid  in  testing  and  maintenance  due  to  the  ability  of 
the  maintenance  personnel  to  review  the  design  and  quickly 
grasp  the  purpose  of  a   process.    This  application  has  been 
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validated  by  a  software  reliability  study  [Ref.  16]  which 
demonstrated  that  procedures  of  already  coded  software  with 
10  or  more  basis  paths  accounted  for  a  much  greater  share  of 
the  errors.  When  processes  are  coded  and  compiled,  their 
complexity  will  increase  by  2  or  3;  therefore,  in  the  soft- 
ware design  the  complexity  should  be  seven  basis  paths. 

The  theory   behind  the  complexity   metric  is  based   on  a 
definition  and  theorem  from  graph  theory. 


Definition  1.  The  cyclomatic  number  v(G)  of  a  graph  G 
with  n  vertices,  e  edges,  and  1  connected  component 
results  in  the  eguation: 


v  (G)  =  e  -  n  +  1  (5.  1) 

Vertices  are  also  known  as  nodes   and  an  edge  can  be  consid- 
ered a  path  from  one  rode  to  another. 


Theorem  1.  In  a  strongly  connected  graph,  the  cyclo- 
matic number  is  equal  to  the  maximum  number  of  linearly 
independent  paths. 


A  strongly  connected  graph  is  one  in  which  there  is  a 
single  entry  point  and  a  single  exit  point.  All  paths  go 
from  the  entry  point  to  the  exit  point.  Furthermore  there  is 
a  path  from  the  exit  joint  to  the  entry  point.  A  module  can 
be  considered  to  be  represented  by  a  strongly  connected 
graph  because  there  is  a  single  entry  point  from  the  calling 
module  and  the  module  returns  control  to  that  entry  point 
when  it  is  through  processing. 

TAhen  a  control  graph  is  drawn  to  represent  the  flew  of 
control  through  a  module,  there  is  usually  no  indication  of 
the  path  from  the  ending  point  to  the  entry  point.  McCabe 
remarks  that   this  edge  does  not   have  to  be  drawn   in,   hut 
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that   it  may   be   accounted  for   by   modifying  equation   5. 1 
resulting  in: 


v  (G)  =  (e  +  1)  -  n  +  1 


(5.2) 


or 


v  (G)  =  e  -  n  +  2 


(5.3) 


Application  of  Theorem  1  to  Graph   G  in  Figure  5. 1  shows 
that  v  (G)  is  5.   This  indicates  that  there  is  a  basis  set  of 


Figure  5. 1    Graph  G. 

five  independent  paths  from  node  'a'  to  node  '1'.  There  is 
no  one  correct  set  cf  independent  paths,  but  there  is  a 
basis  of  five  paths.  For  example,  there  could  be  iterations 
of  a  locp  within  the  module.  The  identification  of  the 
number  of  paths  in  the  basis  set  does  not  tell  how  many 
iterations   as   the   loop   should   be   processed;    that  is 
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determined  by  data  conditions  at  the  decision  points.  Two 
examples  of  sets  of  basis  paths  for  figure  5.1  are  shown  in 
table  6. 


TABLE  6 
Two  sets  of  Basis  Paths 

Set  #1  Set  #  2 

11:  abcegheikl  abdfjkl 

b2:  abdfikl  abceikl 

b3:  abceikl  abdfikl 

b4:  abceghl  abc  (egh) 3eikl 

b5:  abdfjkl  abc  (egh}  *1 

|  The  notation  (egh)3  means  to 
literate  the  loop  (egh)  3  times 


E.   PROCESS  DESCRIPTIONS 

1 .   Model  Building 

The  purpose  of  these  processes  is  to  construct  a 
format  for  new  factors  or  groupings  of  factors.  If  it  is  a 
grouping  cf  factors  being  constructed  then  identify  the 
groups,  the  sub-groups,  the  group,  sub-group,  and  factor 
coefficients  (weights),  each  groups  level  within  the  model, 
and  the  sub-groups  and  factors  of  which  they  are  composed. 
If  there  are  new  factors  being  formatted  then  obtain  their 
factor  identifiers,  factor  types,  characteristics,  and  the 
subjective  impact  of  the  world  and  the  factor  itself  upon 
the  factor.  If  there  are  any  factors  which  impact  upon  the 
factor  being  formatted  then  obtain  their  factor  identifiers 
and  their  subjective  impact  upon  the  factor  being  formatted. 


43 


a.      Scoring    Model   Construction 

Get  the  Factors  (or  Factor)  which  the  manager 
wishes  to  be  part  of  a  model  or  which  will  be  forecast  or 
analyzed   at    a    later    time. 

Inputs:      MODEL_ID  Source:       Manager 
GROUP  Manager 

FACTOR_ID  Manager 

SU3_GR0UP  Process    1.2 

Outputs:    MODE1_STRUCTORE  Destination:    MODEL_STRUCTURE 

File 
FACTOR_ID  Process    1.2 

t.      Sub-Group  Organization 

Arrange  Factors  in  Sub-Groups.  Assign  each 
Factor  a  weighting  value  and  each  Sub-Group  a  weighting 
value.  Criteria  for  placing  factors  together  in  a  Sub-Group 
are  whether  they  are  both  either  "desirable"  or  "undesi- 
rable" and  that  they  can  be  traded  off  against  one  another. 
Otherwise  they  are  in  separate  Sub-Groups.  There  is  no  limit 
to  the  number  of  Sub-Groups  or  Factors  in  a  Sub-Group. 
However,  single  Factors  do  have  to  be  assigned  to  a 
Sub-Group. 

Inputs:    FACTOR_ID  Source:    Process    1.1 
SUB_GROUP_ID  Manager 

SUB_GROOP_WEIGHT  Manager 

FACTOR_WEIGKT  Manager 

Outputs:    SUB_GROUP  Destination:    Process    1.1 

FACTOR    ID  Process    1.3 
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c.   Addition  to  Factor  File 

If  a  Factor  is  a  new  Factor  then  get  all  infor- 
mation necessary  for  use  in  later  analyzing  or  forecasting 
it. 

Inputs:  FACTOR_ID    Source:  Process  1.2 

FACTOR  Manager 

Outputs:  FACTOR      Destination:  FACTOR  File 

2  •   Wo^§l  Management 

The  purpose  of  this  process  is  to  interpret  the  user 
command  and  forward  the  selection  of  the  user  for  either 
analyzing  or  forecasting  of  the  factor  or  model  selected. 
Check  to  see  if  the  selected  factor  or  model  is  in  the  data- 
base. Any  default  values  of  the  selection  are  set  and  the 
overall  validity  of  the  user's  selection  is  verified.  If  it 
is  not  valid  the  user  is  notified  of  that  fact  and  allowed 
to  reenter  a  selection  command. 

a.   Model  Validation 

Ensure  that  the  user  made  a  valid  selection  of 
options  in  his  selection  command. 


Inputs:   USER_SELECT 
USER_SELEC1 
MODEL_STRUCTURE 
FIRM_SELECI 
VALIDATION 

Outputs:  FIRM_SELECT 
FIRM_SELEC1 
FACTOR_ID 
FIRM  SELECT 


Source:   Manager 

Process  6 
Process  2. 2 
Process  2.3 
Process  2.2 

Destination:  Process  4 

Process  6 

Process  5 

Process  2.2 
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t.   Set  Default  Values 

Provide  default  values  for  any  parameters  not 
specified  by  the  manager.  These  default  values  are  a  period 
of  the  forecast  usirg  data  from  15  years  prior  to  the 
present  date  to  15  years  beyond  the  present  date  into  the 
future.  The  default  interval  is  one  year.  For  the  Monte 
Carlo  selections  the  default  number  of  iterations  is  100. 

Inputs:  OSER_SELECT  Source:   Process  2.1 

TODAYS_DATI  Calendar 

MODEI   TROCTURE  MODEL_STRUCTURE  File 

Outputs:  FIRM_3ELECT         Destination:   Process  2.1 

c.   Ensure  Sufficient  Data  Available 

Check  the  Factor  File  to  ensure  that  there  are 
at  least  3  data  points  within  the  user  specified  time  period 
for  each  Factor  necessary  to  the  forecast.  If  the  selection 
is  for  a  cross-impact-analysis  then  this  process  is  not 
necessary. 

Inputs:  FIRM_SELECI  Source:  Process  2.1 

FACTOR  FACTOR  File 

FACTOR_ID  Process  2.1 

Outputs:  VALIDATION  Destination:  Process  2.1 

3  .   Elemen t  Entry 

Ihis  process  allows  operators  to  add  values  tc  the 
factors  in  the  Factor  file.  It  is  a  screen  formatted  entry 
and  allows  little  leeway  for  the  operator.  Errors  are 
possible  if  the  operator  enters  the  wrong  units  for  the 
ELEMENT_VALUE  in  spite  of  the  prompting  by  the  process. 

Inputs:  FACT0R_ID  Source:  Operator 

DATS_OF_OBSERVATION  Operator 

EIEMENT_SOUECE  Operator 
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ELEMENT_VAIQE 
DATE_OF_ENTEY 
UNITS 

Outputs:     ELEMENT_ENTRY 
ENTRY    SCREEN 


Operator 
Calendar 

FACTOR    File 

Destination:  FACTOR  File 
Operator 


4 .   Forecast 

This  group  of  processes  execute  the  forecast  of  the 
model  or  factor  selected  by  the  user.  The  forecast  is  made 
by  fitting  five  types  of  curves  to  the  observed  data.  The 
curve  with  the  highest  correlation  coefficient  is  utilized 
for  the  forecast.  A  default  confidence  interval  of  50%  is 
applied  for  the  forecast.  The  results  of  the  forecast  are 
provided  to  the  manager  in  a  tabular  format.  If  individual 
factors  are  forecast  then  the  results  are  placed  in  the 
Factor  file,  with  an  ELEMENT_ANALYSIS  of  "Estimate", 
ELEMENT_SOUBCE  is  the  CURVE  used  for  the  forecast,  and 
DATE_CF_ENTRY  and  DATE_OF_OBSERV ATION  are  the  date  and  time 
the  forecast  was  completed. 

In  the  case  of  forecasting  models  three  possible 
combinations  are  available.  If  all  of  the  factors  which  make 
up  the  model  have  a  factor  limit  then  a  model  limit  can  then 
be  calculated  by  utilizing  the  factor  limit  in  place  of  the 
factor  values  in  the  scoring  model  and  executing  the  model. 
This  would  enable  Pearl  and  Gompertz  carves  to  be  calcu- 
lated, because  these  curves  require  an  upper  limit  to 
growth.  The  model  can  then  be  executed  as  normal  with  the 
model  limit  used  in  these  two  equations  in  place  of  the 
factor  limit.  If  some  factors  in  a  model  have  no  factor 
limit  then  only  the  linear,  logarithmic,  and  double  loga- 
rithmic curves  are  available  for  fitting. 

Ihere  is  also  the  option  of  forecasting  each  indi- 
vidual factor   along  the   curve  with  the   best  fit   and  then 


47 


substituting  the  estimated  values  for  each  factor  in  the 
model.  When  observed  data  is  not  available  then  this  is 
carried  out  through  a  Monte  Carlo  simulation  using  a  random 
distritution  between  the  upper  and  lower  confidence  limits 
of    the   estimate. 

a.      Limit   Choices 

Determine  the  beginning  and  ending  time  of  each 
interval   of   the    user's    request. 

Inputs:    FIRM_SELECT  Source:    Process    2 

MODEL_STRUCTURE  HODELJSTRUCTURE    File 

FACTOR_LIMIT  FACTOR    File 

Outputs:    BARE_FACTCE_VIEW  Destination:    Process  4.1.3 

EARE_FACTCR_VIEW  Process  4.1.2 

MODEL_STRUCTURE  Process  4.1.2 

MODEL_STRUCTURE  Process  4.1.4 

t.      Check    For  Model    Limit 

Check  to  see  if  Model-Limit  can  be  calculated 
from  data  available.  If  all  Factors  in  a  model  have  a 
Factor-Limit    then    a    Model-Limit    can    be   calculated. 

Inputs:    M0DSL_STRUC1URE  Source:    Process    4.1.1 

FACTOR_LIMIT  Process    4.1.1 

Outputs:    MODEL_LIMIT  Destination:    Process    4.1.4 

c.      Calculate    the   Model-Limit 

Calculate  the  Model-Limit  using  the 

Factor-Limits  for  each  Factor  in  the  model  and  using  the 
Model-Structure    of    th€    designated   Model-Id. 

Inputs:    MODEL_STR0C1URE  Source:    Process    4.1.2.1 

FACTORJLIMIT  Process    4.1.2.1 

Outputs:    MODEL_LIMIT  Destination:    Process    4.1.4 
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d.  Screen    Factor    Values 

Screen  Factor  File  for  historical  data  within  an 
interval.  Calculate  the  average  of  the  values  and  note  the 
number  cf  values  in  each  interval  and  the  last  interval 
which  has  any  historical  data  in  it. 

Inputs:  BARE_FACTOE_VIEW     Source:  Process  4.1.1 
ELEMENT_VAIUE  FACTOR  File 

Outputs:  FACTOR_VIEW        Destination:  Process  4.1.4 
FACTOR_VIEW  Process  4.3 

e.  Scoring  Mcdel 

Ensure  an  interval  has  at  least  one  data  point 
in  it  prior  to  calculating  the  Model-Score.  If  there  are  no 
data  points,  go  to  the  next  interval. 

Inputs:  MODEL_LIMIT  Source:  Process  4.1.2 
MODEL_STRUCT0RE  Process  4.1.1 

FACTOR_VIEW  Process  4.1.3 

FCDEL_SCORE  Process  4.1.4.2 

Outputs:  MODEL_STRUCTURE      Destination:  Process  4.1.4.2 
AVG_VALUE  Process  4.1.4.2 

MODEL_VIEW  Process  4.3 

f.  Calculate   Model-Sccre 

Calculate  score  of  a  single  interval  cf  a  model 
using  the  Model- Structure  and  the  Avg-Values  passed  to  it. 
The  Factors  which  make  up  each  Sub-Group  are  multiplied  by 
their      Factor-Weights        and      then      summed         together.  All 

Sub-Groups  are  multiplied  by  their  Sub-Group  Weights.  The 
Sub-Groups  which  are  the  components  of  each  Group  are  multi- 
plied together  and  then  multiplied  by  the  Group-Weights. 
Desirable      Groups        are      divided         by      undesirable        Groups. 
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Overriding  Groups  multiply  the   entire  model. This  product  is 
the  Hcdel-Score. 


Inputs:  MODEL_STRUCTURE 
AVG  VALUE 


Source:  Process  4.1.4.1 
Process  4.1.4.1 


Outputs:  MODEL_SCORE         Destination:  Process  4.1.4.1 

g.   Initialize  Functions 

Determine  the  set  cf  formulas  which  will  be  used 
to  convert  observed  data  into  a  linear  form.  The  possible 
five  curves  are  the  Pearl  curve,  Gompertz  curve,  linear  (no 
change)  r  a  logarithmic  curve  using  the  natural  logarithm  cf 
the  dependent  variable  (the  element-value),  and  a  double- 
logarithnic  curve  using  the  natural  logarithm  of  both  the 
dependent  (element-  value)  and  independent  variable 
(observation-date) .  If  there  are  no  Factor  or  Model  Limits 
then  the  Pearl  and  Gcmpertz  curves  can  not  be  utilized. 


Inputs:  MODEL_VIEW 
FACTOR_VIEfl 

Outputs:  DATA_POINTS 
AVG_VALUE 
END_INTERVAL 
CURVE 

LIMIT 


Source:    Process    4.1 
Process    4. 1 

Destination:    Process  4.3.1.3 

Process  4.3.1.2 

Process  4. 3.1.2 

Process  4.3.1.2 

Process  4.3.1.2 


h.      Calculate  Curve    Functions 

Adjust  the  Avg-Values  and  Observation-Dates  into 
a  form  which  may  be  linear  using  the  Gompertz,  Pearl, 
Logarithmic,    or    Double-Logarithmic    eguations. 


Inputs:    LIMIT 

AVG_VALUE 

END_INTERVAI 

CURVE 


Source:  Process  4.3.1.1 

Process  4.3.1.1 

Process  4.3.1.1 

Process  4.3.1.1 
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Outputs:    DEPENDENT  Destination:    Process    4.3.1.3 

INDEPENDENT  Process    4.3.1.3 

i.      Calculate   Regression 

Calculate   A,    B,    the    correlation    coefficient,    and 
the      standard    error      cf   B      through      simple    regression.         The 
dependent   variable     (an   adjusted   or    unadjusted   Element-Value) 
is   regressed      on   the      independent    variable       (an    adjusted      or 
unadjusted   Observation-Date). 

Inputs:    DEPENDENT  Source:  Process  4.3.1.1 

DATA_POINTS  Process  4.3.1.1 

INDEPENDENT  Process  4.3.1.1 

LAST_03SERVED_INTERVAL  Process  4.3.1.1 

Outputs:    REGRESS_ANALYSIS  Destination:    Process  4.3.2 

REGRESS_ANALYSIS  Process  4.3.3 

REGRESS_ANALYSIS  Process  4.3.4 

REGRESS_ANALYSIS  Process  4.3.5 

REGRESS_ANALYSIS  Process  4.3.6 

j.      Pearl  Curve   Forecast 

Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Pearl  curve  formula,  then 
calculate  the  estimated  value  for  the  data  with  an  upper  and 
lower  limit  for  a  50$  confidence  interval.  This  information 
is  provided  for  each  interval  from  the  end  of  observed  data 
to    the    End-Period    of    the    user    request. 

Inputs:    VARIATE  Source:    Process    4.3.1 

IDENTIFIER  Process    4.3.1 

REGRESS_ANAIYSIS  Process    4.3.1 

FACTOR_VIEw  Process    4.3.1 

MODEL_VIEW  Process    4.3.1 

Outputs:    EX?ANDED_ECDEL_VIEW        Destination:    Manager 
EXPANDED_FACTOR_VIEW  Manager 
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EXPANDED_IACTOR_VIEW 
k.   Gompertz  Curve  Forecast 


Process    4.3.1 


Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Gompertz  curve  formula,  then 
calculate  the  estimated  value  for  the  data  with  an  upper  and 
lower  limit  for  a  50$  confidence  interval.  This  information 
is  provided  for  each  interval  from  the  end  of  observed  data 
to   the    End-Period   of    the    user    reguest. 


Inputs:    VARIATE 

IDENTIFIER 
REGRESS_ANAIYSIS 
FACTOR_VIEW 
MODEL    VIEW 


Source:  Process  4.3.1 

Process  4.3.1 

Process  4.3.1 

Process  4.3.1 

Process  4.3.1 


Outputs:    EXPANDED_MCDEL_VIEW        Destination:    Manager 
EXPANDED_FACTOR_VIEW  Manager 

EXPANDED_fACTOR_VIEW  Process    4.3.1 

1.      Linear  Curve   Forecast 

Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Linear  curve  formula,  then 
calculate  the  estimated  value  for  the  data  with  an  upper  and 
lower  limit  for  a  50$  confidence  interval.  This  information 
is  provided  for  each  interval  from  the  end  of  observed  data 
to    the    End-Period    of    the    user    reguest. 


Inputs:    VARIATE 

IDENTIFIER 
REGRESS_ANAIYSIS 
FACTOR_VIEW 
MODEL    VIEW 


Source:    Process  4.3.1 

Process  4.3.1 

Process  4.3.1 

Process  4.3.1 

Process  4.3.1 


Outputs:    EXPANDED_MCDEL_VIEW         Destination:    Manager 
EXPANDED_PACTOR_VIEW  Manager 

EXPANDED    IACT0R    VIEW  Process    4.3.1 
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id.      Log    Curve   Forecast 

Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Logarithmic  curve  formula, 
then  calculate  the  estimated  value  for  the  data  with  an 
upper  and  lower  limit  for  a  50%  confidence  interval.  This 
information  is  provided  for  each  interval  from  the  end  of 
observed    data    to    the    End-Period    of    the    user    request. 

Inputs:    VARIATE  Source:    Process  4.3.1 

IDENTIFIER  Process  4.3.1 

REGRESS_ANAIYSIS  Process  4.3.1 

FACTOR_VIEW  Process  4.3.1 

MODEL_VIEW  Process  4.3.1 

Outputs:    EXPANDED_MCDEL_VIEW         Destination:    Manager 
EXPANDED_PACTOR_VIEW  Manager 

EXPANDED_IACTOR_VIEW  Process    4.3.1 

n.       Double-Log   Curve    Forecast 

Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Double-Logarithmic  curve 
formula,  then  calculate  the  estimated  value  for  the  data 
with  an  upper  and  lower  limit  for  a  50%  confidence  interval. 
This  irfcrmation  is  provided  for  each  interval  from  the  end 
of    observed   data    to    the    End-Period   of    the   user    request. 

Inputs:    VARIATE  Source:    Process    4.3.1 

IDENTIFIER  Process    4.3.1 

REGRESS_ANAIYSIS  Process    4.3.1 

FACTOR_VIEw  Process    4.3.1 

MODEL_VIEW  Process    4.3.1 

Outputs:    EXPANDED_MCDEL_VIEW        Destination:    Manager 
EXPANDED_JACTOR_VIEW  Manager 

EXPANDED    FACTOR    VIEW  Process    4.3.1 
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o.      Monte   Carlo 

Provide  the  actual  Model-Score  and  the  estimated 
Model-Score  over  the  intervals  with  observed  data.  The  esti- 
mate is  arrived  at  through  use  of  the  estimated  factor 
values  for  each  Factor  in  the  model  substituted  in  a  scoring 
model.  For  the  intervals  with  no  observed  data  a  50%  confi- 
dence interval  is  established  using  the  upper  and  lower 
estimates  for  each  Factor  of  the  model  and  substituting  them 
into  a  scoring  model.  Then,  for  number  of  times  specified  by 
the  user,  a  random  value  between  the  upper  and  lower  esti- 
mates for  each  Factor  is  used  for  calculating  the 
Model-Score. 

Inputs:    FIRM_SELECT  Source:    Process    4.1 

EXPANDED_FACTOR_VIEW  Process    4.3 

MODEL_VIEW  Process    4.1 

MODEL_STRUCTURE  Process    4.1 

MGDEL_SCORE  Process   4.4.2 

Outputs:    MONTECARLC_FORECAST    Destination:    Manager 

MODEL_STRUCTURE  Process    4.4.2 

AVG_VALUE  Process    4.4.2 

p.      Calculate   Model    Score 

Calculate  score  of  a  single  interval  of  a  model 
using  the  Model-Structure  and  the  Avg-Values  passed  to  it. 
The  Factors  which  make  up  each  Sub-Group  are  multiplied  by 
their      Factor-Weights        and      then      summed        together.  All 

Sub-Groups  are  multiplied  by  their  Sub-Group  Weights.  The 
Sub-Groups  which  are  the  components  of  each  Group  are  multi- 
plied together  and  then  multiplied  by  the  Group-Weights. 
Eesiralle  Groups  are  divided  by  undesirable  Groups. 
Overriding  Groups  multiply  the  entire  model. This  product  is 
the    Model-Score. 

Inputs:    M0DEL_STRUC1URE  Source:    Process    4.4.1 
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AVG_VALUE  Process  4.4.1 

Outputs:  MODEL_SCORE         Destination:  Process  4.4.1 

5 .   Cross  Impact  Analysis 

This  process  utilizes  the  simple  cross  impact  anal- 
ysis model  devised  by  Kane  as  discussed  in  [Ref.  2].  It 
searches  the  database  for  the  values  it  requires  and  does 
not  require  any  interaction  by  the  user.  Any  changes  tc  the 
model  will  be  made  in  the  Model  Management  process. 

a.  Cross   Impact 

Construct  a  Cross-Impact-Matrix  of  Factors  which 
impact  on  a  single  object  Factor.  This  matrix  also  includes 
the  impacts  of  the  other  Factors  upon  each  other.  The  impact 
of  the  cutside  world  only  impacts  upon  the  Factors;  the 
Factors  do  not  impact  upon  the  outside  world. 

Inputs:  FACTOR_ID  Source:  Process  2.0 

IMPACT_FACTCRS  FACTOR  File 

FACTOR_IMPACTS  FACTOR  File 

Outputs:  CROSS_IMPACT_MATRIX  Destination:  Manager 

CROSS_IMPACT_MATRIX  Process  5.2 

b.  Calculate  Impact 

Over  a  relative  period  of  time  calculate  the 
cumulative  effects  of  the  values  of  the  Cross-Impact-Matrix 
upon  a  set  of  subjective  Initial-Values  provide  by  the 
manager  for  each  Factor. 

Inputs:  CROSS_IMPACT_MATRIX   Source:  Process  5.1 
INITIAI_VAIUE  Manager 

Outputs:  RELATIVE_IIME       Destination:  Manager 
VALUE  Manager 
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6  .       Model   C hanc[e 

The  user  may  change  selected  variables  within  the 
model  which  has  most  recently  been  executed  and  then  execute 
it  again.  For  a  model  forecast  the  Group-Weight, 
Sub-Group-Weight,  and  Factor-Weights  may  be  changed.  If 
desired,  the  modified  model  may  be  given  a  new  nasne  and 
placed  in  the  Model-Structure  file.  The  Factor-Limit  of  a 
Factor  or  of  Factors  in  a  model  may  be  changed  and  the  model 
run  again.  The  selection  parameters  may  be  altered  to  change 
the  time  period  looked  at,  the  interval  within  the  time 
period  or,  if  the  selection  was  for  a  model,  a  Monte  Carlo 
forecast  rather  than  a  regular  forecast  (and  vice  versa)  may 
be    chcsen. 

Inputs:    INITIAL_VA10E  Source:    Process    5 

FACTOR_VIEW  Process   4 

MODEL_STEOCTaRE  Process    4 

CROSS_IMPACT_MATRIX  Process    5 

FIRM_SELECT  Process    2 

GRO0*P_WEIGHT  Manager 

SUB_GROUP_WiIGHT  Manager 

FACTOR_WEIGHT  Manager 

FACTOR_LIMIT  Manager 

MODEL_ID  Manager 

Outputs:    P!ODEL_STRUCTURE  Destination:    Process    4 

MODEL_STRDCTURE  MODEL_STRUCTURE 

File 
FACTOR_VIEW  Process    4 

CROSS_IMPACT_MATRIX  Process    5 

INITIAL   VAIUE  Process    5 
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VI.  APPLICATIONS  OF  THE  DSS 

The  ISDN  concept  is  the  integration  of  digital  voice, 
circuit-switched  data,  and  packet-switched  data  networks 
into  a  single  network.  The  user  of  an  ISDN  would  not  be 
aware  of  which  of  these  types  of  networks  would  be  utilized 
to  complete  a  connecticn  to  a  destination.  The  network  would 
select  the  reguired  type  of  network,  the  choice  of  which 
would  be  transparent  to  the  user,  but  is  accessed  at  a 
single  pcint.  An  ISDN  architecture  for  the  national  backbone 
and  distribution  telecommunications  systems  could  be  desir- 
able by  the  NCS  as  it  would  simplify  the  problem  of  inte- 
grating the  present  mix  of  communications  networks  in  a 
national  emergency. 

The  rate  at  which  an  ISDN  architecture  will  evolve  in 
the  United  States  can  not  easily  be  mandated  by  regulation 
due  to  the  increasing  number  of  private  companies  and 
government  agencies  involved  in  construction  and  maintenance 
of  telecommunications  systems.  As  pointed  out  in  Chapter  1, 
the  impetus  for  growth  of  a  technology  comes  from  a  need  for 
that  technology.  In  the  United  States,  it  is  estimated  that 
private  users  provide  85%  of  the  needs  driving  the  evolution 
of  the  ccmmon  carrier  network.  Only  20%  of  the  private  users 
provide  80%  of  the  use  of  the  common  carrier  networks 
[Eef.  17].  Therefore,  to  forecast  the  growth  of  ISDN  tech- 
nology, it  is  necessary  for  the  manager  to  forecast  the  need 
for  an  ISDN  by  private  users. 

The  forecast  DSS  described  in  this  paper  can  be  utilized 
to  forecast  that  user  need  for  an  ISDN.  The  method  for  doing 
this  is  for  the  NCS  tc  collect  data  on  the  number  of  Private 
Branch  Exchanges  (PBX's)  with  digital  capable  microwave, 
optical  fiber,   or  copper  T-carrier  direct  tie-lines  to  tell 
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or  tandem  switches  with  direct  access  to  the  digital  tack- 
hone  system.  This  data  can  be  expressed  as  a  number  of  tie- 
lines  installed  or  as  a  percentage  of  installed  PBX's  with 
the  tie-lines.  This  is  an  indicator  that  network  users  want 
to  bypass  the  local  distribution  systems  which  are  difficult 
to  use  for  high  speed  digital  communications.  The  number  of 
PBX's  with  tie-lines  can  be  entered  into  the  database  of  the 
DSS.  A  forecast  can  be  generated  of  this  data  by  extrapo- 
lating along  the  growth  curve  with  the  best  fit  to  the  data. 
This  curve  fitting  is  performed  by  the  DSS  and  the  results 
of  the  forecast  are  stored  in  the  DSS  database  for  later 
comparison  and  are  also  presented  to  the  user  in  either 
tabular  cr  graphical  form. 

The  above  example  is  one  of  an  accelerator  for  techno- 
logical growth  of  ISDN  architectures.  It  would  also  be 
desirable  to  forecast  constraints  on  the  development  and 
implementation  of  this  technology.  The  number  of  engineers 
and  maintenance  personnel  trained  to  install  and  maintain  an 
ISDN  is  a  definite  constraint  on  implementation  of  an  ISDN 
architecture  in  the  United  States.  The  data  on  the  number  of 
such  ISDN  trained  personnel  can  be  collected  and  forecast 
using  the  DSS. 

After  a  number  of  acjelerators  and  constraints  have  been 
collected,  a  cross  impact  analysis  of  the  factors  upon  each 
other  can  be  performed  by  the  DSS.  An  analysis  of  this  type 
could  demonstrate  the  relative  impact  of  different  variables 
upon  each  other  to  obtain  an  approximation  of  the  relative 
time  required  to  achieve  a  desired  result.  For  example,  the 
impacts  of  digital  communication  media  cost,  the  nuirber  of 
ISDN  trained  personnel,  and  the  competition  to  provide 
digital  services  upon  ISDN  technology  growth  can  be  modeled. 
The  DSS  is  executed  with  the  impacts  as  subjective  values 
and  are  defined  as  desirable  or  negative  impacts  upon  ISDN 
technology. 
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An  example  cross  impact  matrix  is  given  in  Table  7.   The 
variables  listed  in  the  table  are: 

1.  Digital  communications  media  cost  =  •M1 

2.  Number  of  ISDN  trained  personnel  =  'P' 

3.  Ccmpetition  to  provide  digital  services  =  'C 

4.  Growth  rate  of  ISDN  technology  =  '3' 

The  cross  impact  matrix  indicates  that  the  cost  of  communi- 
cations impacts  negatively  on  the  rate  of  growth,  while  the 
training  of  more  personnel  facilitates  the  training  of  even 
more  personnel.  The  advantage  of  this  model  is  that  it 
demonstrates  the  relative  impact  that  a  combination  of  vari- 
ables can  have  on  the  growth  rates  of  other  variables. 
Figure  6.1  is  the  result  of  executing  the  model  with  the 
values  ficm  the  cross  impact  matrix  of  Table  7. 
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TABLE  7 
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Figure  6.  1    Output  of  Cross  Impact  Analysis. 
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711.  CONCLUSIONS 

The  National  Communications  System  has  been  tasked  with 
the  overall  responsibility  for  planning  a  national  security/ 
emergency  preparedness  telecommunications  system  [Ref.  17]. 
An  automated  decision  support  system  which  can  aid  NCS 
managers  in  making  effective  forecasts  of  telecommunications 
technology,  prices  and  costs  would  be  an  invaluable  tool  for 
the  conduct  of  this  planning.  This  work  has  described  the 
logical  design  of  such  a  system.  The  design  is  general 
enough  to  allow  maximum  flexibility  in  the  eventual  conver- 
sion to  a  physical,  coded  implementation.  It  will  not  be 
difficult  to  code  this  design  in  a  higher  order  language 
such  as  Ada,  COBOL,  or  BASIC.  More  importantly,  the  logical 
design  cf  this  DSS  lends  itself  toward  implementation 
utilizing  a  fourth  generation  language  such  as  FOCUS  or 
NOMAD.  The  ability  of  these  type  of  packages  to  access  data 
through  a  database-  type  format  allows  a  non-programmer  to 
take  this  design  and  create  a  database  which  can  be  accessed 
by  simple  routines  written  in  the  generic  language  which 
accompanies  these  packages. 

Furthermore,  the  design  of  this  forecast  DSS  can  be 
implemented  on  any  size  computer  from  a  desktop  microcom- 
puter up  to  a  large  mainframe.  The  designation  cf  a 
specific  system  to  run  this  package  at  this  stage  of  the 
design  is  not  necessary  nor  is  it  desirable.  The  end  product 
that  a  user  should  be  looking  for  is  an  acceptable  logical 
design,  not  an  up  and  running  system.  With  a  logical  design 
the  user  can  change  computer  systems  without  having  to  have 
all  of  his  software  redesigned.  It  will  be  simple  to  have  it 
coded  for  the  new  system  or  implement  it  himself  with  a 
fourth  generation  package  as  described  earlier. 
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The  modular  design  of  .is  system  enables  expansion  of 
the  forecast  routines  w  h  little  effort.  The  models 
selected  for  this  design  were  chosen  for  their  simplicity 
and  ease  of  understanding  by  the  user.  A  complex  econometric 
model  may  be  more  accurate  (though  that  has  been  debated  by 
professionals  in  the  field  [ Ref .  18]  ),  but  the  simplicity 
of  simple  regression  models  is  more  intuitive  to  the 
manager.  Two  possible  simple  models  could  be  added,  an  expo- 
nential smoothing  model,  and  a  moving  average  model.  However 
the  seasonal  or  normalizing  techniques  which  accompany  these 
models  are  not  so  simple  and  depend  on  many  more  assumptions 
than  a  simple  regression  extrapolation.  Through  the  use  of 
the  scoring  model  ccnstruction  technique,  the  manager  can 
build  simple  multivariable  bootstrap  models.  Such  models 
have  been  shown  to  model  reality  to  a  remarkable  degree 
[Ref,  18].  In  any  case,  this  system's  strict  adherence  to 
structured  techniques  and  modularity  would  facilitate  any 
future  modification  or  expansion  brought  about  by  the 
dynamic  nature  of  the  telecommunications  environment  and  the 
possibility  of  changes  in  overall  system  requirements. 
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APPENDIX  A 
ESSENTIALS  OF  STRUCTURED  DESIGN 

Stevens  et  al.  [ Ref .  19]  introduced  the  concept  of 
structured  design  as  a  comprehensive  method  for  reducing  the 
growing  complexity  of  program  design.  Because  it  is  not  a 
true  methodology,  it  is  used  most  effectively  in  consonance 
with  other  techniques,  such  as  structured  programming, 
structured  analysis,  and  HIPO  hierarchy  charts.  The  key  to 
structured  design  is  reducing  the  logical  view  of  the  system 
into  simple  pieces,  called  modules,  that  can  be  readily 
understood  and  hence  constructed.  The  rationale  behind  this 
concept,  common  with  most  modern  software  design  techniques, 
lies  with  principles  of  behavioral  science  regarding  the 
human  ability  to  comprehend  and  solve  problems  faster  when 
they  are  of  manageable  size  and  complexity.  These  princi- 
ples were  the  basis  for  top-down  design,  which  calls  for 
decomposing  large,  complex  problems  into  smaller,  less 
complex  problems,  until  the  original  problem  has  been 
expressed  as  a  combination  of  many,  small,  solvable  prob- 
lems. However,  top-down  design  alone  is  not  sufficient  for 
ensuring  modules  that  are  easy  to  maintain  and  modify. 
Structured  design  includes  the  concept  of  top-down  design, 
along  with  other  strategies  and  heuristics.  Among  these  are 
coupling  and  cohesion. 

Coupling  is  a  measure  of  the  strength  of  association 
between  separate  modules  within  a  system.  The  greater  the 
degree  of  coupling,  the  harder  it  is  to  understand,  change, 
or  correct  a  module  and  hence  the  more  complex  and  compli- 
cated the  system.  One  goal  of  structured  design  is  to 
create  modules  with  coupling  as  weak  as  possible.  This  can 
be  achieved,   at   least  in  theory,   by   designing  the  module 
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interface  to  be  simple  and  obvious  and  ensuring  the  connec- 
tion between  modules  is  to  the  normal  module  interface  (the 
entry  point)  rather  than  to  module  internal  components. 

Modules  share  a  common  environment  when  they  interface 
with  the  same  storage  area,  data  region  or  device.  Ccmmon 
environments  often  provide  complex  paths  along  which  errors 
can  travel  when  a  change  is  made  to  one  module.  When  ccmmon 
environments  are  originally  designed  into  a  system,  add-on 
modules  will  also  be  forced  to  interface  via  the  common 
environment,  further  degrading  the  product.  Limiting  ccmmon 
environment  access  to  the  smallest  possible  subset  of 
modules  tends  to  minimize  this  potential  problem.  Another 
method  to  achieve  lew  coupling  is  to  restrict  interface 
connections  to  obvious  relationships  and  avoid  those  that 
are  inferred.  Thus,  connections  which  refer  to  a  module  as 
a  whole  require  less  coupling  than  those  which  refer  to  an 
internal  component  of  a  module.  This  latter  case  is  called 
pathological  connecticn,  and  is  one  of  the  strongest  forms 
cf  coupling  between  modules.  It  can  be  avoided  by  ensuring 
a  subroutine  executes  only  when  it  is  called  formally  by  a 
module,  it  operates  strictly  on  data  passed  by  the  calling 
module,  only  that  data  essential  to  the  performance  of  its 
task  is  passed  to  the  subroutine,  and  all  results  of  its 
operations  are  returned  to  the  calling  module. 

Cohesion  is  defined  as  the  strength  of  association  of 
the  elements  within  a  module,  and  is  measured  by  a  term 
called  binding.  The  goal  is  to  strive  for  high  binding, 
which  directly  results  in  reduced  coupling  by  minimizing  the 
relationships  ameng  modules.  The  levels  of  cohesion  may  be 
addressed  separately,  scaled  from  low  to  high,  and  although 
a  module  may  exhibit  nultiple  levels  of  binding,  the  highest 
that  may  be  applied  determines  the  module  level. 

1.   Coincidental   tinding  means   there   is  no   meaningful 
relationship  among  the  internal  elements  of  a  module. 
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It  usually  stems  from  haphazard  attempts  at  breaking 
code  up  into  "modules"  or  consolidating  duplicate 
coding  from  several  modules  into  one  "module". 

2.  Logical  binding  means  there  exists  some  kind  of 
logical  relationship  among  the  elements  of  a  module. 
It  often  results  from  "cute",  difficult  to  modify, 
shared  code,  or  from  passing  unnecessary  arguments. 

3.  Temporal  binding  means  the  elements  are  logically 
related  also  in  time.  Such  elements  are  executed 
during  a  common  period  of  time.  The  reason  such 
modules  are  higher  on  the  cohesion  scale  is  that  all 
the  elements  are  at  least  executed  at  once. 

4.  Communicational  binding  means  that  elements  are 
related  further  to  the  same  input/output  data  set. 

5.  Sequential  binding  means  that  elements  within  a 
module  are  processed  sequentially.  It  usually 
results  from  literal  transformation  of  flowchart 
procedural  blocks  to  modules.  However,  procedural 
processes  can  encompass  more  than  one  function. 

6.  Functional  binding  means  all  the  elements  of  a  module 
are  related  to  the  performance  of  a  single  function. 
It  is  the  strongest  level  of  binding.  In  practice, 
the  determination  of  what  exactly  constitutes  a  func- 
tion is  a  difficult  task,  further  compounded  by  the 
dilemma  of  deciding  how  far  to  divide  functionally 
bound  subf unctions. 

Although  there  iray  well  be  a  basic  tradeoff  to  be 
confronted  between  "structural  design"  modules  and 
execution/memory  overhead,  there  are  a  number  of  reasons  why 
a  structured  design  nay,  indeed,  enhance  execution  time/ 
memory  space  required.   The  major  reasons  are: 

1.  Error  modules  (called  "optional")  may  never  be  called 
from  memory. 
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2.  Other,  well-designed  modules  may  only  be  executed  i 
minimum  number  of  times. 

3.  Structured  design  reduces  the  amount  of  duplicate  or 
redundant  code. 

The  structured  design  process  is  divided  into  two 
phases:  general  progiam  design  and  detailed  design.  General 
program  design  is  described  as  deciding  what  the  program 
functions  will  be,  and  detailed  design  as  deciding  how  the 
functions  will  be  implemented.  The  overall  design  goal 
remains  the  structure  of  functionally  bound,  simply 
connected  modules.  The  technique  is  simply  top-down, 
modular,  hierarchical  with  a  unique  graphical  format.  The 
following  guidelines  may  be  helpful  when  utilizing  the 
structured  design  process: 

1.  In  crier  to  enhance  maintainability,  ensure  the 
structure  of  the  design  matches  the  structure  of  the 
problem.  Subsequent  changes  to  the  problem  will  then 
affect  a  minimal  number  of  modules. 

2.  Strive  for  simple  designs  where  the  scope  of  effect 
of  a  decision  is  restricted  to  the  scope  cf  control 
of  the  module  containing  the  decision.  This  is 
accomplished  by  either  moving  the  decision  element  up 
in  the  structure  chart,  or  by  moving  the  entire 
module  containing  the  decision  so  that  it  falls 
within  the  scope  of  control. 

3.  Use  module  size  as  an  indicator  of  potential  prob- 
lems. A  module  that  is  extremely  small  may  not 
perform  a  complete  function.  A  module  that  is 
extremely  large  may  include  more  than  one  function. 

4.  It  is  acceptable  to  design  modules  that  return  binary 
error  or  end-cf-file  flags.  However,  the  same  module 
should  not  be  concerned  with  error  recovery. 

5.  Duplicate  code  may,  under  certain  circumstances,  be 
acceptable.  Euplicate  functions,  however,  should  be 
eliminated. 
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6.  Particular  data  structures  should  be  isolated  in  a 
minimum  number  of  modules.  This  will  facilitate 
module  changes  due  to  subsequent  alterations  in  that 
data  structure's  specifications. 

7.  Minimize  the  number  of  parameters  passed  between 
modules.  The  goal  is  tc  pass  only  that  data  required 
by  the  module  to  accomplish  its  function. 

There  are  several  important  variations  of  the  lasic 
structured  design  methodology.  DeMarco  [Ref.  12]  proposes 
an  approach  that  begins  with  the  codification  of  the  func- 
tional specification,  or  translating  the  prose  specification 
into  working  fixed-fcrmat  documents  (data  flow  diagrams, 
data  dictionary,  transform  descriptions,  data  structure 
chart).  This  step  cculd  actually  be  considered  "structured 
analysis".  The  next  step  is  the  derivation  of  the  structure 
chart,  a  modular  hierarchy  chart  which  records  major  design 
decisions  and  philosophy.  Structure  charts  are  recommended 
rather  than  flowcharts  because  flowcharts  violate  the  prin- 
ciple of  information  hiding  by  exposing  critical  design 
decisions  too  early  in  the  design  process  (for  example,  in 
what  order  and  under  what  conditions  functions  are 
performed) .  Additionally,  structure  charts  depict  module 
connections  and  calling  parameters,  are  smaller  in  size  and 
generally  more  manageable.  In  the  DeMarco  version  module 
design  occurs  next  through  construction  of  module  descrip- 
tions. The  final  step  is  packaging  the  design,  or  shaping 
the  logical  design  to  accommodate  the  physical  environment 
(machine,  operating  system,  coding  language,  memory  limita- 
tions, time  restrictions).  The  key  is  to  construct  an 
environment-independent  design  first,  maximizing  cohesion 
and  mininizing  coupling,  then  impose  packaging  constraints 
so  as  to  minimize  degradation  of  product  quality.  An  impor- 
tant structured  design  principle  is  to  delay  packaging  as 
long  as  possible   in  order  to  "hide"   the  significant  nature 
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of  the  design  problem,   to   include  algorithms,   data  struc- 
tures and  other  transformations. 

Enforcement  of  structured  design  techniques  should 
significantly  reduce  the  effort  required  for  program  modifi- 
cation and  maintenance,  if  modules  possess  weak  coupling  and 
strong  cohesion.  Similarly,  modules  may  be  programmed, 
tested,  and  even  optimized  independently  using  these  tech- 
niques. Structured  desiqn  should,  as  a  minimum,  provide  for 
"predictable"  modules.  These  are  modules  which  perform 
identically  and  consistently  each  time  they  are  called, 
given  identical  inputs.  Predictable  modules  also  tend  to 
perform  independently  of  their  environment.  It  is  not 
clear,  however,  that  strict  adherence  to  structured  design 
will  ultimately  result  in  a  "library"  of  generalized, 
application-independent  modules  that  may  be  easily  config- 
ured to  iitplement  any  sophisticated,  complex  system.  In  the 
final  analysis,  structured  design  is  a  method,  not  a  method- 
ology, and  is  to  be  used  with  other  methods  and  tools  to 
facilitate  the  design  of  programs. 
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APPENDIX  B 
PROCESS  MINI-SPECIFICATIONS 


************************************************************ 
1. 1  SCORING  MODEL  CONS1RUCTION 

Inputs:   MODEL  ID  Source:   Manager 
GROUP  Manager 

FACTOR  ID  Manager 

SUB_GRUUP  Process  1.2 

Outputs:  MODEL  STRUCTURE      Destination:  MODEL  STRUCTURE 

File 
FACTOR  ID  Process  1.2 


A.  Identify  FACTOR_IEs  that  relate  to  how  well  the 

technology  performs. 

B.  Eliminate  overlays  of  ELEMENTS  from  the  model  that 

measure  the  same  or  very  similar  characteristics. 

D.  For  each  FACTOR  IE  in  the  model 

E.  Do  SU3_GR0UP"0RGANIZATI0N 

F.  End  For. 

G.  For  each  SUB  GROUP  ID 

H.      If  each  SUB_GBCTTP  is  of  such  an  overriding  nature  that 
it  must  be  present  or  the  score  of  the  model  equals 
zero  then 

I.         Assign  this  SUB  GROUP  to  be  the  sole  member  of  a  GROJ P 

J.         Assign  this  GROUP  a  GROUP  ID 

K.         Assign  a  GFCUP  LEVEL  =  0  ~ 

L.         Assign  a  GRCUP_TYPE  =  "Override" 
Else 

M.         If  SUB  GROUP  is  desirable  then 

N.  Assign  to  a  GROUP  with  GROUP_TYPE  =  "Desirable" 

Else 

0.  Assign  to  a  GROUP  with  GROUP  TYPE  =  "Undesirable". 

P.         End  If 

Q.      End  If 

R.   End  For 

S.   For  each  GROUP 

T.      If  GROUP_TYPE  is  not  equal  to  "Override"  then 

U.         Assign  a  GECUP  ID. 

V.         Assign  a  GBCUP~LEVEL  =  1. 

W.      End  If 

X.   End  For 

Y.   Assign  each  GROUP  a  subjective  GROUP_WEIGHT. 

Z.   Assign  the  model  a  M0DEL_ID. 
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TABLE  8 
Process  1.1  Easis  Paths 


Complexity  Metric:  7 

1  atcfgrsxyz 

2  atcdefgrsxyz 

3  atcf ghi jklgrsxyz 
M  atcf ghmnpgrsxyz 

5  atcfghmopgrsxyz 

6  atcf ghmopgrstwxyz 

7  atcf ghmopgrstuvwxyz 


************************************************************ 
1.2  SUB_GROUP  ORGANIZATION 

Inputs:  FACTOR  ID  Source:  Process  1.1 
SOB  GRQUP  ID  Manager 

SUB"GROUP~WEIGHT  Manager 

FACTOR_WETGHT  Manager 

Outputs:  SUB  GROUP  Destination:  Process  1.1 
FACTOR  ID  Process  1.3 


A.  Do  ADDITION  TO  FACTOR  File 

E.  If  FACTORS  can  be  traded  off  against  FACTORS  in 
a  SUB  GROUP  then 

C.  Assign  FACTOR  tc  that  same  SUB_GROUP. 

D.  Assign  a  FACTOR_WEIGHT 
E  lse 

E.  Assign  FACTOR  as  sole  member  of  a  new  SUB  GROUP 

F.  Assign  a  FACTOR  WEIGHT 

G.  Assign  a  SUB  GFTUP  ID. 

H.     Assign  a  subjective  SUB  GROUP  WEIGHT. 
I.  End  If  " 
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TABLE  9 
Process  1.2  Basis  Paths 


Complexity  Metric:  2 

1 .  abcdi 

2.  abefghi 


************************************************************ 
1.3  ADDITION  TO  FACTOR  FILE 

Inputs:  FACTOR_ID    Source:  Process  1.2 
FACTOR  Manager 

Outputs:  FACTOR  Destination:  FACTOR  File 


A.  Check  the  FACTOR  ID  against  the  FACTOR  File 
E.  If  it  is  not  present  then 

C.  Get  the  FACTOR  ID  along  with  the  FACTOR  TYPE 

and  CHARACTERISTIC  from  Manager 

D.  If  the  FACTOR  TYPE  =  "Objective"  then 

E.  Get  the  UNTIS  and  the  FACTOR  LIMIT  from  Manager 

F.  End  If 

G.  End  If 

H.  Get  FACTOR  IMPACT  of  the  FACTOR  upon  itself 

I.  Get  FACTOR~IMPACT  of  the  OUTSIDE  WORLD  upon  the  FACTOR 

J.  If  there  are  FACTORS  which  impact  on  this  FACTOR  then 

K.     Provide  the  FACTOR  IDs 

L.      Eo  ADDITION  TO  FACTOR  FIIE 

M.     If  these  impacting  FACTOR  IDs  are  not  already 

listed  in  the  FACTOR  File  as  impacting  on  the 

object  FACTCR  then 
N.        Get  the  subjective  FACTOR  IMPACT 
C.     End  If 
P.  End  If 
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TABLE  10 
Process  1.3  Basis  Paths 


Complexity  Metric:  5 

1  .  atghiip 

2.  atcdefghijp 

3.  alcdfgnijp 
H.  alghijklmnop 
5.  arghijklmop 


************************************************************ 

2.1  MCDEI  VALIDATION 

Inputs:   USER  SELECT  Source:   Manager 

USER~SELECT  Process  6 

MODEL  STRUCTURE  Process  2.2 

FIRM  SELECT  Process  2.2 

VALIDATION  Process  2.3 

Outputs:  FIRM  SELECT  Destination:  Process  4 
FIRM~SELECT  Process  6 

FIRM~SELECT  Process  2.2 

FACTOR  ID  Process  5 


A.  If  a  FACT0R_ID  is  in  the  USER_SELECT  and  CHOICE  equals 

"Forecast"  then 

B.  If  FACTOR  ID  is  present  in  the  FACTOR  File  then 

C.  Do  SET~DEFAULTS 

D.  Do  ENSURE  SUFFICIENT  DATA  AVAILABLE 

E.  End  If. 
Else 

F.  If  a  MODEL  ID  is  in  the  USER  SELECT  then 

G.  Do  SET  EEFAtLTS 

H.  If  CHOICE  =  "Cross  Impact"  then 

I.  VALIDATION  =  "Not  Valid" 

J.  End  If. 

K.  If  VALIDATION  =  "Valid"  then 

L.  Get  the  f ACTOR  IDs  from  the  MODEL  STRUCTURE 

M.  For  each  FACTOR"  ID 

N.  Do  ENSURE  SUTFICIENT  DATA  AVAILABLE 

C.  End  For 

P.  End  If. 

C-  End  If. 

R.  End  If. 
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TABLE  11 
Process  2. 1  Basis  Paths 


Complexity  Metric:  7 

1 .  arer 

2.  afccder 

3.  afgr 

4.  afghjkpgr 

5.  afghijKpgr 

6.  afgh jklmnopqr 

7.  afgh jklmopgr 


*********************************************************** 
2.2  SET  DEFAULT  VALUES 

Inputs:  USER  SELECT  Source:   Process  2. 1 

TODAYS  DATE  Calendar 

M0DEL_5TRUCTURE  MODEL_STRUCTURE  Pile 

Outputs:  FIRM_SELECT         Destination:   Process  2.1 


A.  VALIDATION  =  "Valid" 

B.  If  IDENTIFICATION  =  MODEL  ID  and  MODEL  ID  is  not  in  the 

MODEL  STRUCTURE  File  fhen 

C.  VALIDATION  =  "Net  Valid" 
Else 

D.  Get  TODAYS  DATE 

E.  If  BEGIN  PERIOD  =  Null  then 

F.  BEGIN~PERIOE  =  TODAYS  DATE  -  15yrs 

G.  End  If.  ~ 

H.  If  END  PERIOD  =  Null  then 

I.  END~PERIOD  =  TODAYS  DATE  +  15yrs 

J.  End  IfT 

K.  If  BEGIN  PERIOD  >=  END  PERIOD  then 

I.  Selection  is  not  valid 

M.  End  If. 

N.  If  INTERVAL  =  Null  then 

0.  INTERVAL  =  1yr 

P.  End    If. 

C.  If    CHOICE    =    "Mcnte   Carlo"    and    ITERATIONS    =    Null    then 

R.  ITERATIONS    =    100 

S.  End    If. 

T.  End    If. 
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TABLE  12 
Process  2.2  Basis  Paths 


Complexity  Metric:  7 

1 .  atct 

2.  atdeghj kmnpgst 

3.  atdefgh jkmnpqst 

4.  atdeghi ikranpgst 

5.  atdeghj klmnpgst 

6.  atdeghj kmnopgst 

7.  atdeghj kmnpgrst 


2.3  ENSURE  SUFFICIENT  DATA  AVAILABLE 

Inputs:  FIRM  SELECT  Source:  Process  2.1 

EACTOR  FACTOR  File 

FACTOR_ID  Process  2. 1 

Outputs:  VALIDATION  Destination:  Process  2. 1 


A.  If  CHCICE  =  "Monte  Carlo"  cr  "Forecast"  and  at 
least  three  ELEMENT  ENTRYs  with  an 
ELEMENT  ANALYSIS  equal  to  "Historical" 
are  NOT~present  with  DATE  OF  OBSERVATION 
between  BEGIN  EERIOD  and  "END~PERIOD  then 

E.     VAIIDATION  =  "Not  Valid" 

C.  End  If. 


TABLE  13 

Process  2.3  Basis  Paths 

Complexity  Metric:  2 

1  .  ate 
2.  ac 

i 

7a 


************************************************************ 
3.0  ELEMENT  ENTRY 

Inputs:  FACTOR  ID  Source:  Operator 
EATE  OP  OBSERVATION  Operator 

ELEMENT~SOURCF  Operator 

ELEMENT~VALUE  Operator 

LATE  OF~ENTRY  Calendar 

UNITS   "  FACTOR  File 

Outputs:  ELEMENT  ENTEY  Destination:  FACTOR  File 
ENTRY_SCREEN  Operator 


A.  If  FACTOR  ID  is  in  FACTOR  File  then 

B.  Display  ENTRY  SCREEN 

C.  Enter  DATE  OF~CESERVATION 

D.  Enter  ELEME~NT"SCURCE 

E.  Enter  ELEMENT"VALUE 

F.  ELEMENT_ANALY5IS  =  "Historical" 

G.  Combine  with  DATE  OF  ENTRY  and  store  in  FACTOR  File 
H.  End  If  ~  " 


TABLE 

14 

Process 

3.0 

Ba 

sis 

Paths 

Complexi 

ty 

Met 

ric : 

2 

1. 

2. 

ah 
alcd 

ef  g 

h 
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Process 

4.  1.3 

Process 

4.  1.2 

Process 

4.1.2 

Process 

4.  1.4 

************************************************************ 
4.  1.  1    LIMIT    CHOICES 

Inputs:    FIRM   SELECT  Source:    Process    2 

model:   STRUCTURE  MODEL    STRUCTURE    File 

FACTOE_LIMIT  FACTOE    File 

Outputs:    BARE    FACTOR    VIEW  Destination 

BAPE"FACTOR"VIEW 
MODEL"    STRUCTURE 
MODEL~STRUCT0RE 


A.  INTERVAL    NUMBER    =   0 

B.  END    INTERVAL(O)     =    BEGIN    PERIOD 

C.  While    END    INTERVAI (INTERVAL    NUMBER)     <    END    PERIOD 

D.  INTERVAL    NUMBER    =    INTERVAL    NUMBER    +     1    ~ 

E.  BEGIN    INTERVAL  (INTERVAL    NUflBER)    = 

ENE    INTERVAL7INTERVAL    NUMBER    -     1) 

F.  END    INTERVALflflTERVAL    NUMBER)     =    " 

BEGIN    INTERVAL (INTERVAL    NUMBER)     +    INTERVAL 

G.  End  While. 

H.  LAST  INTERVAL  =  INTERVAL  NUMBER 

I.  If  MCDEL_ID  is  in  FIRM_SELECT  and  CHOICE  =  "Forecast" 

then 

J.  For  each  FACTCR  ID  in  MODEL  STRUCTURE 

K.  Do  SCREEN  FACTOR  VALUES  " 

L.  End  For. 

M.  Do  CALCULATE  MCDEL  LIMIT 

N.  INTERVAL  NUMBER  =  1 

0.  While  INTERVAL  NUMBER  <=  LAST  OBSERVED  INTERVAL 

P.  Do  SCORING  "BODEL 

Q.  INTERVAL_NUMBER  =  INTEEVAL_NUMBER  +  1 

R.  End  While. 

S.  End  If. 


TABLE  15 
Process  4.1.1  Basis  Paths 


Complexity  Metric:  5 

1.  atcdefghis 

2.  alcghis 

3.  atcghi jlmnors 

4.  alcghijklmnors 

5.  atcghi j lmnopgrs 
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********** *********************************** *************** 
4.  1.2.1   CHECK  FOR  MCEEL  LIMIT 

Inputs:  MODEL  STRUCTURE      Source:  Process  4.1.1 
FACTOH_LIMIT  Process  4.1.1 

Outputs:  MODEL_LIMIT         Destination:  Process  4.1.4 


A.  Fcr  each  FACTOR  IE  in  MODEI  STRUCTURE 

E.  If  FACTOR  LITTI1  =  Null  tfTen 

C.  MODEL  LIMIT  =  Null 

D.  End  If.  ~ 
t.  End  For. 

F.  If    MODEL   LIMIT   <>   Null    then 

G.  Do    CALCULATE    MCDEL    LIMIT 
H.  End    If. 


TABLE    16 

Process    4.1.2.1    Basis  Paths 

Complexity   Metric:    4 

1.  aefh 

2.  atdefh 

3.  atcdefh 

4.  atcdefgh 
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********************  **************************************** 

4. 1.2.2   CALCULATE  MODEL  LIMIT 

Inputs:  MODEL  STRUCTUBE      Source:  Process  4.1.2.1 
EACTOF_LIMIT  Process  4.1.2.1 

Outputs:  MODEL_LIMIT         Destination:  Process  4.1.4 


A.  Fcr  Each  GROUP 

B.  If  GROUP  IEVEL  =  1 

C.  For  each  SUB  GEOUP 

D.  Sum  the  value  of  the  FACTOE  LIMITS  multiplied 

by  the  FACTOE  WEIGHTS  of  each  FACTOR  ID 

E.  Multiply  this  sura  T5y  the  SUB  GEOUP  WEIGHT" 

F.  Remember  this  as  the  SUB_GROUP_VALUE 

G.  End  For 

H.         Multiply  the  SUB  GROUP  VALUES  together 

I.         Multiply  the  SUB~GEOUP~VALUE  by  the 
GROUP  WEIGHT" 

J.  Remember  This  as  the  GROUP  VALUE 

K.      End  If. 

L.   End  For. 

M.       If    there  are    2    groups    with    a    GEOUP    LEVEL   =    1    then 

N.  DIVIDE    THE   GEOGP    VALUE    of    the    GROUP    which    has   a 

GROUP   TYPE  =~"Desirable"    by    the    GROUP    VALUE 
of    the   GROUP    which    has   GROUP_TYPS   equal    to 
"Undesirable" 

0.  Remember    this    number   as    MODEL    LIMIT 
P.       End    If 

Q.       For    each   GROUP 

E.  If    GROUP    IEVEL   =    0 

S.  GROUP~VALUE   =    FACTOR    LIMIT    *    GROUP    WEIGHT 

1.  Multiply   the    GROUP    VILUE   times    t he~MODEL_LIMIT 
U.                     Remember    this   result   as    the    MODEL   LIMIT 

V.  End    If. 

W.       End    For. 


TABLE  17 

Process  4.1.2.2  Basis  Paths 

Complexity  Metric:  7 

1 .  almpqw 

2.  almpqrvw 

3.  atklmpqw 

4.  almpqrstuvw 

5.  atcgnijklmpqw 

6.  afccdef ghi jklmpgw 

7.  almnopqw 
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Jit*********************************************************** 
4.1.3  SCREEN  FACTOR  VALUES 

Inputs:  EARE  FACTOR  VIEW     Source:  Process  4.1.1 
ELEMENT_VALUE  FACTOR  File 

Outputs:  FACTOR  VIEW        Destination:  Process  4.1.4 
FACTOR"VIEW  Process  4.3 


A.  For  each  INTERVAL  KUMBER 

B.  If  EATE  OF  OBSERVATION  is  greater  than  or  egual 

to  HEGIN  INTERVAL (INTERVAL  NUMBER)  and  less 
than  END~INIERVAL (INTERVAL~NUMBER)  then 

C.  TOTAL  =  TDTAI  +  ELEMENT  VALUE 
E.         OBSERVED  =  CESERVED  +  1~ 

E.  LAST  OBSERVED  INTERVAI  =  INTERVAL  NUMBER 

F.  End  If." 

G.  AVG_VALUE  =  TOTAI  /  OBSERVED 
H.  End  For. 


TABLE  18 

■ 

Process 

4.  1.3  Basis  Paths 

Cottplexity  Metric:  3 

1.  atfgh 

2.  ah 

3.  atcdefgh 
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************************************************************ 
4.  1.  4. 1  SCORING  MODEL 

Inputs:  PODEL  LIMIT  Source:  Process  4.1.2 
MODEL~STRUCTURE  Process  4.1.1 

FACTOR  VIEW  Process  4.1.3 

M0DEL_5C0RE  Process  4.1.4.2 

Outputs:  MODEL  STRUCTURE  Destination:  Process  4.1.4.2 
AVG  VALUE  Process  4.1.4.2 

MODEL  VIEW  Process  4.3 


A.  INTERVAL  NUMBER  =  1 

B.  While  INTERVAL  NUMBER  <=  LAST  OBSERVED  INTERVAL 

C.  GCOD  INTERVAL  =1 

D.  Fcr  each  FACTCP  ID  in  model 

E.  If  OBSERVED  =  0  then 

F.  GOOD  INTERVAL  =  0 

G.  End  If." 
H.  End  For. 

I.  If  GOOD  INTERVAL  =  1  then 

J.  Do  CALCULATE  MODEL  SCORE 

K.  OBSERVE  =  1 

Else 

L.  OBSERVE  =  0 

M.  MCDEL  SCORE  =  0 

N.  End  If.  ~ 

C.  INTERVAL  NUMBER  =  INTERVAL  NUMBER  +  1 

P.  End  While   " 

Q.  Combine  data  into  KODEL  VIEW 


TABLE  19 
Process  4.1.4.1  Basis  Paths 


Complexity  Metric:  5 

1 .  alpg 

2.  alcdhilmnopg 

3.  atcdeghilmnopg 

4.  abcdefghilmnopg 

5.  atcdefghi jknopg 
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************************************************************ 
4.1.4.2   CALCULATE  MCEE1_SC0RE 

Inputs:  MODEL  STRUCTURE      Source:  Process  4.1.4.1 
AVG_VA"LUE  Process  4.1.4.1 

Outputs:  MCDEL_SCORE         Destination:  Process  4.1.4.1 


A.  Fcr  Each  GROUP 

B.  If  GROUP  LEVEL  =  1 

C.  For  each  SUE  GROUP 

D.  Sum  the  value  of  the  AVG  VALUES  multiplied  by 

the  FACTOR  WEIGHT  ofeach  FACTOR  ID 

E.  Multiply  this  sum  by  the  SUB  GROUP  WEIGHT 

F.  Remember  this  as  the  S U B_G R OH P_ VALUE 

G.  End  For 

H.         Multiply  the  SUB  GROUP  VALUES  together 

I.         Multiply  the  SUB~GROUP~VALUE  by  the 
GROUP  WEIGHT" 

J.         Remember  This  as  the  GROUP  VALUE 

K.      End  If. 

L.   End  For. 

M.   If  there  are  2  groups  with  a  GROUP  LEVEL  =  1  then 

N.      DIVIDE  THE  GRCUP  VALUE  of  the  GHOUP  which  has  a 
GROUP  TYPE  =~"Desirable"  by  the  GROUP  VALUE 
of  the  GROUP  which  has  3ROUP_TYPE  equal  to 
"Undesirable" 

0.      Remember  this  number  as  MODEL  SCORE 

P.   End  If 

Q.       For  each  GROUP 

R.       If  GROUP  LEVEL  =  0 

S.  GFOUP~VALUE  =  AVG  VALUE  *  GROUP  WEIGHT 

T.         Multiply  the  GROUP  VALUE  times  The  MODEL_SCORE 

U.         Remember  this  result  as  the  MODEL  SCORE 

V.      End  If. 

W.   End  Eor. 


TABLE  20 
Process  4.1.4.2  Basis  Paths 


Complexity  Metric:  7 

1 .  almpqw 

2.  atklmpgw 

3.  abcghijklmpgw 

4.  atcdefghi jklmpqw 

5.  almnopqw 

6.  almpqrvw 

7.  almpqrstuvw 


4.3.1.1    INITIALIZE    FUNCTIONS 


Inputs:     MODEL   VIEW 
FACTOR*    VIEW 


Source 


Process  4. 1 
Process  4. 1 


Outputs: 


DATA  POINTS 
AVG  VALUE 
END~INTERVAL 
CURVE 
LIMIT 


Destination 


Process  4 
Process  4 
Process  4 
Process  4 
Process  4 


3.1.3 
3.  1.2 
3.  1.2 
3.  1.2 
3.  1.2 


A.  If    FACTOR    LIMIT    =    Null    then 

B.  PICK   =~Set    [■ linear* | 'Log' | ' Double-Log' ] 
E  Is  e 

C.  PICK   =    Set    [' Pearl" | "Gompertz* I'Linear" I'Log' |fDoutle-L3g"  ] 

D.  LIMIT  =  FACTOR  LIMIT 

E.  End  If. 

F.  For  CURVE  =  FIRST'LAST  of  set  PICK 

G.  1  =  0 

H.  CCUNT  =  1 

I.  While  COUNT  <=  LAST  OBSERVED  INTERVAL 

J.  If  OBSERVE  (COUNTf  >  0  then 

K.  1  =  1+1 

L.  Do  CURVE  FUNCTION 

M.  End  If 

N.  COUNT  =  COUNT  +  1 

0.  End  While. 

P.  EATA  POINTS  =  I 

C.  Do  CALCULATE  REGRESSION 

R.  End  For 

S.  Co  SELECT  CURVE 


TABLE  21 
Process  4.3.1-1  Basis  Paths 


Complexity  Metric:  5 

1.  atefrs 

2.  acdefrs 

3.  atefghiopqrs 

4.  alef ghi jmnopgrs 

5.  alef ghi jklmnopgrs 
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************************************************************ 
4.3.1.2  CALCULATE  CUEVE  FUNCTIONS 

Inputs:  LIMIT  Source:  Process  4.3.1.1 

AVG  VALUE  Process  4.3.1.1 

END~INTERVAL  Process  4.3.1.1 

CURVE  Process  4.3.1.1 

Outputs:  DEPENDENT  Destination:  Process  4.3.1.3 

INDEPENDENT  Process  4.3.1.3 


A.  Choose  from  the  following: 

CURVE  =  Pearl 
E.         DEPENDENT  =  IOG  (LIMIT  /  AVG  VALUE  -  1) 

C.  INDEPENDENT  =  END_INTERVAL   ~ 
CURVE  =  Gompertz 

D.  DEPENDENT  =  IOG  (LOG  (LIMIT  /  AVG  VALUE  )  ) 

E.  INDEPENDENT  =  END  INTERVAL 
CURVE  =  Linear 

F.  DEPENDENT  =  AVG  VALUE 

G.  INDEPENDENT  =  ElTD_INTER  VAL 
CURVE  =  Logarithmic 

H.         DEPENDENT  =  IOG  (AVG  VALUE) 
I.         INDEPENDENT  =  END  INTERVAL 

CURVE  =  Double  logarithmic 
J.         DEPENDENT  ="IOG  (AVG  VALUE) 
K.         INDEPENDENT  =  LOG  (ETJD_INTERVAL) 
L.   End  Choice. 


I 

TABLE  22 

Process  4.3.1.4  Basis  Paths 

Conplexity  Metric:  5 

1.  atcl 

2.  adel 

3.  afgl 

4.  ahil 

5.  ajkl 
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***********************-   ********************************** 
4.3.1.3  CALCULATE  REGRE.  ^ON 

Inputs: 


DEPENDENT            Source: 

Process 

U. 3.  1.  1 

DATA  POINTS 

Process 

4.3.  1.  1 

INDEPENDENT 

Process 

4.3.  1.  1 

LAST  OBSERVED  INTERVAL 

Process 

4.3.  1.  1 

Outputs:  REGRESS  ANALYSIS  Destination:  Process  4.3.2 

REGRESS-ANALYSIS  Process  4.3.3 

REGRESS~ANAIYSIS  Process  4.3.4 

REGRESS~ANAIYSIS  Process  4.3.5 

REGRESS~ANALYSIS  Process  4.3.6 


A.  Define  Function  R  (Z)  =  A  +  B  *  Z 

B.  For  I  =  1  to  LAST  OBSERVED  INTERVAL 

C.  P  =  P  +  DEPENDENT 

D.  C  =  Q  +  (DEPENDENT  **  2) 

E.  R  =  R  +  INDEPENDENT 

F.  S  =  S  +  (INDEPENDENT  **  2) 

G.  0  =  U  +  (DEPENDENT  *  INDEPENDENT) 
H.  End  For. 

I.  S1  =  DATA  POINTS  *  S  -  R  **  2 

J.  M2  =  R  /  UATA  POINTS 

K.  B  =  (DATA  POITTTS  *  U  -  P  *  R)  /  S1 

L.  A  =  JP  -  B  *  R)  /  DATA  POINTS 

M.  V    =    E    *    SQR     (S1    /    (DATA"    POINTS    *    Q    -    P    **    2)  ) 

N.  For    I    =    1    to    DATA    POINTS 

0.  N  (I)    =    Fn    R     (INDEPENDENT) 

P.  OJIJ     =    DEPENDENT    -    N  (I) 

Q.  End  For. 

R.  For  I  =  1  to  DATA  POINTS 

S.      01  =  01  +  0(1)-**  2 

T.  End  For. 

U.  02  =  01  /  (DATA  ECINTS  -  2) 

V.  03    =    SQR     (02)       ~ 

W.  B1    =     (SQR     (DATA    PCINTS)     *    C3)     /    SQR     (S1) 

X.  VARIATE   =    0.688~fcr    a   50%    confidence    interval 

Y.  Forecast  CURVE    with    highest   correlation   factor    =>    V 


TABLE    23 
Process   4.3.1.3   Basis  Paths 


Complexity   Metric:    4 

1.  athi jklmnqrtu vwxy 

2.  atcdefqhijklniDqrtuvwxy 

3.  athi jklmnop jr tuvwxy 

4.  alhi jklmnqrstuvwxy 
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4.3.2  PEARL  CURVE  FORECAST 


Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL_VlEW 

Outputs:  EXPANDED  MODEL  VIEW 
EXPANDED~FACTOK  VIEW 
EXPANDED~FACTCR~VIEW 


Source:  Process 
Process 


4.3.  1 
4.3.  1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 


Destination:  Manager 
Manager 
Process  4.3.1 


A.  Define  Func 

B.  Define  Func 

C.  Define  Func 


D.  Print  'A  = 

E.  Print  »B  = 

F.  Print  'Corr 

G.  Print  ■ Stan 
H.  INTERVAL  = 
I.  While  INTER 
J.  ESTIMATE 
K.  UPPER  = 

I.  ICWER  = 

M.  INTERVAL 

N.  End  While. 

0.  INTERVAL  = 

P.  While  INTER 

Q.  ESTIMATE 

R.  UFPER  = 

S.  LCWER  = 

T.  INTERVAL 

U.  End  While. 


tion 
tion 
tion 


'  :-B 
elat 
dard 
1 

VAL 

=    F 
ESTI 

*  Fu 
ESTI 

*  Fu 
=    I 

LAS'11 
VAL 


EXP  (A) 


=    A    + 

=    LIM 
=    03 
(DAT 
*     ( 


B  ♦  7 
IT  /  (1  +  EXP(Z)  ) 
*  SQR  (1  +  1  / 
A  POINTS  +  (DATA  POINTS 
Z~-  M2)  **  2)  /  5"1)  ) 


ion  Coeffic 
Error  of  B 

<=  LAST_OBS 
unction  P ( 
MAIE  +  (  VA 
nction  F (  E 
MAIE  -  (  VA 
nction  F (  E 
NIERVAL  ♦  1 

OBSERVED  I 

?:=  LAST  mi 


=    Function  P ( 
ESTIMATE  +  (  VA 

*  Function  F (  E 
ESTIMATE  -  (  VA 

*  Function  F (  E 


=  INTERVAL  + 


ient  =« ;CORRELATION 
=  ';B1 

ERVED  INTERVAL 

Function  R(  END  INTERVAL)  )  ) 

RIATE 

ND  INTERVAL)  ) 

RIETE 

ND  INTERVAL)  ) 


NTERVAL  +  1 

ERVAL  NUMBER 

Function  R(  END  INTERVAL)  )  ) 

RIATE 

ND  INTERVAL)  ) 

RIITE 

ND  INTERVAL)  ) 


TABLE  24 

Process  4.3.2  Basis  Paths 

Complexity  Metric:  3 

1  .  alcdefghinopu 

2.  abcdefghi jklmncpu 

3.  alcdef ghinopgrstu 
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************************************************************ 
4.3.3    GCMPERTZ    CURVE    FORECAST 


Inputs:     VARIATE 

IDENTIFIER 
REGRESS    ANALYSIS 
FACTOR    VIEW 
MODELJ7IEW 

Outputs:    EXPANDED    MODEL    VIEW 
EXPANDED-FACTOK    VIEW 
EXPANDED~FACTCR~VIEW 


Source:  Process  4.3.1 

Process  4.3.1 

Process  4.3.1 

Process  4.  3. 1 

Process  4.3.1 

Destination 


Manager 
Manager 
Process  4 


3.1 


A. 
B. 
C. 


D. 
E. 
F. 
G. 
H. 
I. 
J. 
K. 


M. 
N. 
C. 
P. 

Q. 

R. 


T. 
U, 


Define 
Define 
Define 


Fun 
Fun 
Fun 


ction 
ction 
ction 


R  (Z) 

GiZ' 
Efzj 


Print 
Print 
Print 
Print 

INTERV 
While 

EST 
UFD 


•B  = 
fK  = 
♦Cor 
•Sta 
AL  = 
INTE 
IMAT 
ER  = 


LCWER  = 


INT 

End  Wh 

INTERV 

While 

EST 

UEP 


ERVA 
ile. 
AL  = 

INTE 
IMAT 
ER  = 


■  ;EX 
•;-B 

re  la  t 
ndard 

1 
RVAL 

E  =  F 
ESTI 

*  Fu 
ESTI 

*  Fu 
L  =  I 


P(A) 


A  +  B  *  Z 

LIMIT  *  EXP(-EXP(Z)  ) 
03  *  SQR  (1  +  1  / 
(DATA  POINTS  +  (DATA  POINTS 
*  (Z~-  M2)  **  2)    /  SI) ) 


icn  Coefficient  =  ' 
Error  of  K  ='  ;B  1 


CORRELATION 


<=  LAST 
unction 
MATE  +  ( 
nction  F 
MATE  -  ( 
nction  F 
NTERVAL 


OBSERVED  INTERVAL 

G(  Function  R(  END  INTERVAL) 

VARIATE 
(  END  INTERVAL)  ) 

VARIITE 
(  END  INTERVAL)  ) 
+  1   " 


)  ) 


INT 
End  Wh 


LAST  OBSERVED  INTERVAL  +  1 
RVAL  ?=  LAST_ITJTERVAL_NUMBER 
E  =  Function  G (  Function  R ( 

ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL) 
LCWER  =  ESTIMATE  -  (  VARIlTE 

*  Function  F(  END  INTERVAL) 
L  =  INTERVAL  ♦  1   " 


erva: 
ile. 


END_INTERVAL)  ) 
) 
) 


TABLE 

25 

Process 

4.3.3 

Basis 

Paths 

Com 

plexity  Metric:  3 

1. 
2. 

3. 

atcdefghinopu 
atcdef ghi jklmnopu 
atcdefghinopqrstu 
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************************************************************ 
4. 3.4  LINEAR  CURVE  FORECAST 


Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL  VIEW 


Source:  Process  4.3.1 
Process  4.  3. 1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 


Outputs: 


EXPANDED 

EXPANDED" 

EXPANDED" 


MODEL  VIEW 
FACTOR"  VIEW 
FACTCR~VIEW 


Destination: 


Manager 
Manager 
Process  4.3 


C. 

D. 
E. 
F. 
G. 
H. 
I, 
J. 


L. 

M. 
N. 
0. 
?, 

Q. 


s. 
T. 


Define  Function 
Eefine  Function 


•Int 

•Slo 
'Cor 
»Sta 


Print 
Print 
Print 
Print 

INTERVAL  = 

WHILE  INTE 

ESTIMAT 

UPPER  = 

LOWER  = 

INTERVA 

End  While. 

INTERVAL  = 

While  inte 

ESTIMAT 

UPPER  = 


ercept 

pe  =  * 
relati 
ndard 

1 
RVAL  < 
E  =  Fu 

ESTIM 

*  Fun 
ESTIM 

*  Fun 
L  =  IN 


LAST 
rval  ?T 

E  =  Fu 
ESTIM 

*  Fun 
LOWER  =  ESTIM 

*  Fun 
INTERVAL  =  IN 

End  While. 


R(Z)  =  A  + 
F  Z)  =  03 
(DAT 
*  ( 

=  \A 

;e 

en  Coeffic 
Error  of  S 

=  LAST_0BS 
notion  R  ( 
ATE  +  (  VA 
ction  F  (  E 
ATE  -  I  VA 
ction  F  (  E 
TERVAL  +  1 

CESERVED  I 
=  LAST_IflT 
nction  R  ( 
AIE  +  (  VA 
ction  F  (  E 
ATE  -  (  VA 
ction  F  (  E 
TERVAL  +  1 


B  *  Z 
*  SQR  (1+1 
A  POINTS  +  (D 
Z~-  M2)  **  2) 


/ 


ATA  POINTS 
/  51)) 


ient  =f  .-CORRELATION 
lope  =• ; B1 

ERVED  INTERVAL 

END  INTERVAL)  ) 

RIATE 

ND    INTERVAL)     ) 

BUTE 

ND    INTERVAL)     ) 


NTERVAL    +     1 

ERVAL  NUMBER 

END  INTERVAL) 

RIATE 

ND  INTERVAL)  ) 

BUTE 

ND  INTERVAL)  ) 


TABLE  26 
Process  4.3.4  Basis  Paths 


Complexity  Metric:  3 

1.  atcdefghmnot 

2.  atcdefghi jklmnct 

3.  atcdefghmnopqrst 


4.3.5  LOG  CURVE  FORECAST 

Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL_VlEW 

Outputs:  EXPANDED  MODEL  VIEW 
EXPANDED~FACTOR  VIEW 
EXPANDED" FACTOR" VIEW 


A.   Eef ine  Function  R  (Z)  =  A  +  3  *  Z 

E.   Define  Function  F  (Z)  =  .03_*  SQE  (1_*  1  / 


Source: 

Process 
Process 
Process 
Process 
Process 

4.3. 

4.3. 
4.3. 
4.3. 

4.3. 

1 
1 
1 
1 
1 

Destination : 

Manager 
Manager 
Process 

4.3 

(DATA  POINTS  +  (DATA  POINTS 
*  (Z~-  M2)  **  2)  /  S1)  ) 
C.   Print  'Constant  Term  =  '  ;EX?(A) 


D.  Print  'Growth  Rate  =  ' :  B 

E.  Print  'Correlation  Coefficient  ='; CORR ELATION 

F.  Print  'Standard  Error  of  Growth  Rate  =';B1 

G.  INTERVAL  =  1 

H.   While  INTERVAL  <=  LAST  OBSERVED  INTERVAL 

I.      ESTIMATE  =  EXP(  Function  R(  END  INTERVAL)  )  ) 

J.  UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 
K.      LCWER  =  ESTIMATE  -  (  VABIA"TE 

*  Function  F(  END  INTERVAL)  ) 
L.       INTERVAL  =  INTERVAL  +  1   " 

M.   End  While. 

N.   INTERVAL  =  LAST  OESERVED  INTERVAL  +  1 

C.   While  INTERVAL  ^=  LAST  INTERVAL  NUMBER 

P.      ESTIMATE  =  EXPJ  Function  R(  END  INTERVAL)  )  ) 

Q.       UPPER  =  ESTIMATE  +  (  VAEIATE 

*  Function  F (  END  INTERVAL)  ) 
R.       LCWER  =  ESTIMATE  -  I     VARIA~TE 

*  Function  F(  END  INTERVAL)  ) 
S.       INTERVAL  =  INTERVAL  +  1   ~ 

T.   End  while. 


TABLE  27 

Process 

4.3.5  Basis  Paths 

Complexity  Metric:  3 

1 .  atcdefghmnot 

2.  afccdefghi jklmnct 

3.  atcdefghmnopgrst 

. 
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Source: 

Process 
Process 
Process 
Process 
Process 

4.3. 
4.3. 
4.3. 
4.3. 
4.3. 

1 
1 
1 

1 
1 

Desti 

nation : 

Manager 
ianager 
Process 

4 

4.3.6  DO0BLE_L0G  CURVE  FORECAST 

Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
EACTOR  VIEW 
MODEL_VlEW 

Outputs:  EXPANDED  MODEL  VIEW 
EXPANDED~FACTOH  VIEW 
EXPANDED~FACTCR~VIEW  Process  4.3.1 


A.  Define  Function  R  (Z)  =  A  +  B  *  Z 

B.  Define  Function  F  (ZJ  =  03  *  SQR(1  +  1  / 

(DATA  POINTS  +  (DATA  POINTS 
*  (Z~-  M2)  **  2)  /  51)  ) 

C.  Print  'Constant  =  ';EXP(A) 

D.  Print  'Power  =  • ;E 

E.  Print  'Correlation  Coefficient  =' CORRELATION 

F.  Print  'Standard  Error  of  Power  =';B1 

G.  INTERVAL  =  1 

H.   While  INTERVAL  <=  LAST  OBSERVED  INTERVAL 

I.      ESTIMATE  =  EXPJ  Function  RJ  IOG (  END  INTERVAL)  )  )  ) 

J.       UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 
K.      LOWER  =  ESTIMATE  -  (  VARIITE 

*  Function  F(  END  INTERVAL)  ) 
I.       INTERVAL  =  INTERVAL  +  1   ~ 

M.   End  While. 

N.   INTERVAL  =  LAST  CESERVED  INTERVAL  +  1 

0.   While  INTERVAL  <-   LAST  INTERVAL  NUMBER 

P.      ESTIMATE  =  EXPJ  Function  R(  IIOG  (  END  INTERVAL)  )  )  ) 

Q.       UPPER  =  ESTIMATE  +  J  VARIATE 

*  Function  F(  END  INTERVAL)  ) 
R.      LOWER  =  ESTIMATE  -  J  VARIITE 

*  Function  F(  END  INTERVAL)  ) 
S.       INTERVAL  =  INTERVAL  +  1   " 

T.   End  While. 


TABLE  28 
Process  4-3.6  Basis  Paths 

Complexity  Metric:  3 

1.  atcdefghmnot 

2.  ahcdefghi jklmnct 

3.  ahcdefghmnopgrst 
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Process 

4.  1 

Process 

4.3 

Process 

4.  1 

Process 

4.  1 

Process 

4.4 

************************************************************ 
4.4. 1   MCNTE  CARLO 

Inputs:  FIRM  SELECT  Source 

EXPANDED  FACTCR  VIEW 
MODEL  VIEW 
MODEL~STRUCTURE 
MGDEL~SCORE 

Outputs:  MONTECARLO  FORECAST  Destination:  Manager 

MODEL  STRUCTURE  Process  4.4.2 

AVG  VA"LUE  Process  4.4.2 


A.  For  each  FACTOR  IE  in  MODEL  STRUCTURE 

E.  Do  CURVE_FUNCTION 

C.  End  For 

D.  INTERVAL  NUMBER  =  1 

E.  While  INTERVAL  NUMBER  <=  LAST  OBSERVED  INTERVAL 

F.  Do  CALCULATE  MODEL  SCORE   " 

G.  AVG  VALUE  =  ESTIMATE ( FACTOR  ID) 
H.  Do  CALCULATE  MODEL  SCORE 

I.  ESTIMATE (MODEI  ID)  =  MODEL  SCORE 

J.  INTERVAL  NUMBER"  =  INTER VAL~NUMBER  +  1 

K.  Print  using  OESEBVED  DATA  FORMAT 

L.  End    While. 

M.  While    INTERVAL    NUMBER    <=    LAST    INTERVAL    NUMBER 

N.  AVG    VALUE    =~ESTIMATE  ( FACTOR"    ID) 

0.  Do   CALCULATE    MODEL    SCORE 

P.  ESTIMATE (MODEI    ID)     =    MODEL    SCORE 

Q.  AVG    VALUE    =    UPPERfFACTOR    ID") 

R.  Do   CALCULATE    MCDEL    SCORE" 

S.  UPPER  (MODEL    IE)    =    MODEL    SCORE 

T.  AVG    VALUE    =~LCWER  (FACTOR"    ID) 

U.  Do   CALCULATE    MCDEL   SCORE" 

V.  LOWER (MODEL    IE)     =    MODEL    SCORE 

W.  Print   using~ESTIMATED    DITA    FORMAT 

X.  COUNT  =1              ~ 

Y.  While  COUNT  <=  ITERATIONS 

Z.  For  each  FACTOR  ID  in  MODEL  STRUCTURE 

A'.  AVG  VALUE  =~ (  (UPPER  (FACTOR  ID) 

-  LOWER  (FACTOR  TD) ) 

*  RANDOM_NUMBEK)  +  LOWER ( FACTOR_ID) 

E1  .  End  For. 

C  Do  CALCULATE  MODEL  SCORE 

D«.  FREQUENCY  (INTERVAL  NUMBER , COUNT)  =  MODEL  SCORE 

F»  .  COUNT  =  CODNT  +  1  " 

F«.  End  While. 

G'.  INTERVAL_NUMBER  =  INTERVAL_NUMBER  +  1 

H*.  Print  Frequency  Distribution 

I'.  End  While. 
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TABLE  29 

Process  4.4.1  Basis 

Paths 

Complexity  Metric:  6 

1.  acdelmi' 

2.  arcdelmi' 

3.  acdefghi jklmi  ' 

4.  acdelmnopqrstuvwxyf 'g *h 'i * 

5.  acdelmnopqrstuvwxyzb'c' d'e'f * ( 

j'h'i1 

6 .  acdelmnopqrstuvwxyza •b'c'd'e' J 

E»g»h'i« 

4.4.2   CALCULATE  MODEI_SCORE 

Inputs:  MODEL  STRUCTURE      Source:  Process  4.4.1 
AVG_VA~LUE  Process  4.4.1 

Outputs:  MODEL_SCORE         Destination:  Process  4.4.1 


A.   Fcr  Each  GROUP 

E.       If  GROUP  LEVEL  =  1 

C.  For  each  SUE_GROUP 

D.  Sum  the  value  of  the  AVG  VALUES  multiplied  by 

the  FACTOR  WEIGHTS  for  each  FACTOR  ID 

E.  Multiply  this  sum  by  the  SUB  GROUP  WEIGHT 

F.  Remember  this  as  the  SOB_GROTJP  VALUE 

G.  End  For 

H.  Multiply    the    SUB    GROUP    VALUES    together 

I.  Multiply    the    SUB~GROUP~VALUE    by    the 

GROUP     WEIGHT" 

J.  Remember   This    as   the    GROUP    VALUE 

K.  End    If. 

I.       End    For. 

M.   If  there  are  2  groups  with  a  GROUP  LEVEL  =  1  then 

N.      DIVIDE  THE  GROUP  VALUE  of  the  GKOUP  which  has  a 
GROUP  TYPE  =~"Desirable"  by  the  GROUP  VALUE 
of  the  GROUP  which  has  GROUP_TYPE  equal  to 
"Undesirable" 

0.      Remember  this  number  as  MODEL  SCORE 

P.   End  If 

Q.   For  each  GROUP 

R.       If  GROUP  LEVEL  =  0 

S.  GROUP~VALUZ  =  AVG  VALUE  *  GROUP  WEIGHT 

T.         Multiply  the  GROUP  VALUE  times  The  M0DEL_SC0RE 

U.         Remember  this  result  as  the  MODEL  SCORE 

V.      End  If. 

W.   End  Eor. 
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... 

TABLE 

30 

Process 

4.4. 

.2 

Basis 

Paths 

Con 

flexity  Metric:  7 

1. 

2. 
3. 
4. 

c 

6. 
7. 

almpqw 

arklmpqw 

arcghijklmpqw 

alcaefghi jklmpgw 

almnopgw 

almpgrvw 

almpgrstuvw 

************************************************************ 
5.1  CROSS  IMPACT 

Inputs:  FACTOR  ID  Source:  Process  2.0 

IMPACT~FACTOES  FACTOR  File 

FACTOR"IMPACTS  FACTOR  File 

Outputs:  CROSS  IMPACT  MATRIX  Destination:  Manager 

CROSS~IMPACT~MATRIX  Process  5.2 


A.  Identify  the  FACTCE  ID  to  observe 

B.  Get  list  of  IMPACT  TACTORs 

C.  N1  =  Number  of  IMEICT  FACTORS 

D.  For  OBJECT  =  FIRST'LAST  of  set  of  IMPACT  FACTORS 

E.  Get  list  of  IMPACT  FACTORS  for  each  OBJECT 

F.  For  IMPACT  =  FIBSTTLAST  cf  set  of  IMPACT  FACTORS 

G.  If  the  IMPACT  FACTOR  is  not  listed  in~the  WORK 

File  as  an  IMPACT_FACTOR  on  the  OBJECT 

then 
H.  CROSS_IMPACT_MATRIX (  OBJ ECT, IMPACT  )  =  0 

Else 
I.  CROSS  IMPACT  MATRIX  (  OBJECT, IMPACT  )  = 

FA"CTCR  IMPACT 
J.        End  If 
K.     End  For. 

I.     IMPACT  =  OUTSIDE  WORLD 

M.     CRCSS_IMPACT_MATEIX (  OBJECT, IMPACT  )  =  WORLD  IMPACT 
N.  End  For. 
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TABLE  31 

Process  5. 1  Basis  Paths 

Complexity  Metric:   4 

1 .  ahcdn 

2.  atcdefklmn 

3.  alcdefgi jklran 

4.  atcdef ghjklmn 

5.2  CALCULATE  IMPACT 

Inputs:  CFOSS  IMPACT  MATRIX  Source:  Process  5.1 
INITISL_VALUE  Manager 

Outputs:  RELATIVE  TIME  Destination:  Manager 
VALUE    "  Manager 


A.  RELATIVE    TIME    =    0 

B.  For    CBJECT=    FIRST'LAST    of    set    of    IMPACT    FACTORS    S 

OUTSIDE    WORLD 

C.  Do    CALCUIATE    INITIAL    VAIUE 

D.  VALUE (OBJECT)     =    INITTAL_VALUE 

E.  End  For 

F.  TIME  INTERVAL  =  0.001 

G.  For  RELATIVE  TIME=  1  to  1000 

H.       For  IMPACT  =  FIRST'LAST  of  set  of  IMPACT  FACTORS 

I.  NEGATIVE (IMPACT)  =  DESIRABLE  (IMP ACT)  =  0 

J.         For  OBJECT=  FIRST'LAST  of  set  of  IMPACT  FACTORS  S 

OUTSIDE  WORLD 
K.  NEGATIVElIMPACT)  =  NEGATIVE (IMPACT) 

♦  (  (ABS  (CROSS  IMPACT  MATRIX  (IMPACT,  OEJECT)  )  ) 
-  CECSS  IMPACT  MATRIX (IMPACT, OBJECT) ) 

*  VAIUETOBJECTf 
L.             DESIRABIE(IMPACT)  = 


:RABIE(IMPACT)  =  DESIRABLE  (IMPACT) 
+  ((AES  (CROSS  IMPACT  MATRIX  (IMPACT .OBJECT) ) ) 
+  CROSS  IMPACT  MATRIX  (IMPACT, OBJECT) ) 


*    VAIUE~[OBJECTj" 
M.  End    For. 

N.  E  (IMPACT)     =     (1    +    TIME    INTERVAL    *     (0.5) 

*  NEGATIVE (IMPACT))  / 

(1  +  TIME  INTERVAL  *  (0.5) 

*  DESIRABIE  (IMPACT)  ) 
O.      End  For. 

P.       For  IMPACT  =  FIRST'LAST  of  set  of  IMPACT  FACTORS 

Q.  VALUE  (IMPACT)  =  VALUE (IMPACT)  **  E  (IMPACT) 

R.         If  VALUE  (IMPACT)  <=  1.0  **  (-70)   then 

S.  VALUE  (IMEACT)  =  0 

T.         End  If. 

U.      End  For. 

V.   End  for 
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TABLE  32 
Process  5-  2  Basis  Paths 


Complexity  Metric:   7 

1 .  aief gv 

2.  afccdefgv 

3.  atefghopuv 

4.  abef ghi jmnopuv 

5.  afcef ghi jklmnopuv 

6.  ateghi jmnopgrstuv 

7.  afceghijmnopgrtuv 
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*********************************************************** 
6  MODEL  CHANGE 


Inputs 


Outputs : 


INITIAL  VALOE 

Source: 

Process  5 

PACTOR  VIEW 

Process  4 

MODEL  STRUCTURE 

Process  4 

CROSS~IMPACT  MATRIX 

Process  5 

FIRM  SELECT  " 

Process  2 

GROUP  WEIGHT 

Manager 

SUB  GROUP  WEIGHT 

Manager 

FACTOR  WETGH1 

Manager 

FACTOR~LIMIT 

Manager 

MODEL_TD 

Manager 

MCDEL  STRUCTURE 

Destination:  Process  4 

MODEL~STRUCTURE 

MODEL  STRUCTURE 

File 

FACTOR  VIEW 

Process  4 

CROSS  IMPACT  MATRIX 

Process  5 

INITIII  VALUE 

Process  5 

A. 

Get  FIRM  SELECT 

B. 

If  IDENTIFIER  is  a  MODEL  ID  and  CHANGE  =  "Model"  then 

C. 

Chanqe  one  of  the  follovinq  variables 

D. 

[GROUP  WEIGHT} 
"SUB  GHOUP  WEIGHT] 

E. 

F. 

'FACTOR  WEIGHT} 

G. 

End  If 

H. 

If  CHANGE  =  "Factor"  then 

I. 

For  each  FACTOR  ID 

J. 

Change  FACTCH  LIMIT  if  desired 

K. 

End  For. 

L. 

End  If 

M. 

If  CHANGE  =  "Selection"  then 

N. 

Change  one  of  the  following  variables 
CHOICE 

0. 

P. 

WINDOW 

Q. 

INTERVAL 

R. 

End  Change. 

S. 

End  If. 
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TABLE 

33 

Process 

6 

Basis 

Paths 

Coir 

plexity  Metric: 

5 

1. 

2. 
3. 

4. 

c 

atghlms 
arcdef qhlms 
atghiiKlms 
alghiRlms 
atghlmnopqrs 

96 


APPENDIX  C 
DATA  DICTIONARY 


A.   DATA  FLOW  COMPOSITIONS 

BARE  FACTOR  VIEW      =   FACTOE  ID 

(FACTOR*  LIMIT) 
WINDOW  " 
INTERVAL 
{INTERVAL  NUMBER 
BEGIN  INTERVAL 
END_ INTERVAL} 

EARE  MODEL  VIEW       =   MODEL  ID 

(MODEL  LIMIT) 
WINDOW" 
INTERVAL 

{INTERVAL  NUMBER 
BEGIN  INTERVAL 
END_INTERVAL} 

CROSS  IMfACT  MATRIX   =   FACTOR  ID 

{IMPACT  FACTOR 
FACTOR~IMPACT} 

ELEMENT  ENTRY         =   DATE  OF  OBSERVATION 

{ELEMENT  ANALYSIS 
ELEMENT~SOURCE 
DATE  OF~ENTRY 
ELEMENT~VALUE} 

EXPANEED  FACTOR  VIEW  =   FACTOR  ID 

(FACTOE  LIMIT) 
WINDOW  ~ 
INTERVAL 

LAST  OBSERVED  INTERVAL 
LAST~INTERVAL~NUMBER 
{INTERVAL  NUMBER 
BEGIN  INTERVAL 
END  INTERVAL 
AVG~VALUE 
(ESTIMATE 
UPPER 
LOWER) 
OBSERVED} 
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EXPANDED  MODEL  VIEW   =   MODEL  ID 

(MODEL"_LIMIT) 


WINDOW" 
INTERVAL 

LAST  OBSERVED  INTERVAL 
LAST~INTERVAL~NUMBER 
{INTERVAL  NUMBER 

BEGIN  INTERVAL 

END  INTERVAL 

MODEL  SCORE 

(ESTIMATE 
UPPER 
LOWER) 

03SERVE} 


FACTOR  =       FACTOR    ID 

FACTOR~TYPE 


CHARACTERISTIC 
(UNITS    ♦    FACTOR    LIMIT) 
[IMPACT    FACTOR    " 
FACTOR~IMPACT} 
OUTSIDE-WORLD 
[ELEMENT    ENTRY} 


FACTOR    VIEW  =       FACTOR    ID 

(FACTOR"    LIMIT) 
WINDOW    ~ 
INTERVAL 

LAST    OBSERVED    INTERVAL 
LAST"INTERVAL"NUMBER 
[INTERVAL    NUMBER 

BEGIN  INTERVAL 

END  INTERVAL 

AVG'VALUE 

OBSERVED} 

FIRM  SELECT  =   IDENTIFIER 

CHOICE 
VALIDATION 
WINDOW 
INTERVAL 
(ITERATIONS) 

IDENTIFIER  =      [ MODEL_ID | F ACTOR_I D  ] 
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MODEL    STEUCTURE  =       MODEL    ID 

{GROUP_ID 


GROUP~IEVEL 
3ROUP~WEIGHT 
(GROUP    TYPE) 
{SUB    GlOUP} 


MODEL    VIEW  =      MODEL    ID 


(MODEI  LIMIT) 
R7" 


WINDOW 
INTERVAL 

LAST  OBSERVED  INTERVAL 
LAST~INTERV AL"NUMBER 
{INTERVAL  NUMBER 
BEGIN  INTERVAL 
END  INTERVAL 
MODEL  SCORE 
OBSERVE} 

REGRESS  ANALYSIS      =   IDENTIFIER 

CURVE 
VARIATE 
B 
A 

STANDARD  ERROR 
CORRELATION 
03 
M2 
S1 

SUB  GROUP  =   SUB  GROUP  ID 

SUB~GROUP~WEIGHT 
1  {FICTOR  ID 

FACTOR'WEIGHT} 


USER  SELFCT  =   IDENTIFIER 

CHOICE 


WINDOW) 

AL) 

ITERATIONS) 


INTERVi 


WINDOW  =   BEGIN  PERIOD 

END  PERIOD 
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B.   DATA  ELEMENT  DESCEIPTIONS 

A  =   type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 

AVG_VALUE  =   type  is  digits  7 

*  Average  of  all  data  elements  in 
a  defined  interval  * 

First  defined  in  4.0 

E  =   type  is  FLOAT 

*  Temporary  variable  in 
regression  calculation  * 

BEGIN_INTEEVAL  =   type  is  range  0..100_000 

*  Julian  date  representation  of 
the  date  of  the  beginning  of  an 
interval.  Base  year  is  1900  * 

BEGIN_EEEIOD  =   type  is  range  0..100_000 

*  Julian  date  representation  of 
the  date  of  the  beginning  of 
a  period.  Base  year  is  1900  * 

CHARACTERISTIC  =   type  is  (Endogenous, Exogenous) 

*  Identifies  whether  a  FACTOR  is 
within  users  control  or  not  * 

CHOICE  =   type  is  (Forecast,  Monte-Carlo, 

Cross-Matrix) 

*  Identify  whether  to  run  a 
forecast  model  or  the  cross- 
impact  simulation  * 

CORREIAIICN  =   type  is  digits  7  range  0.0..  1.0 

*  This  is  the  R  **  2  result  of 
regression  analysis  * 
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CURVE 


DATE  OE  ENTRY 


LATE  OF  OBSERVATION 


ELEMENT  ANALYSIS 


ELEMENT  SOURCE 


ELEMENT  VALUE 


END  INTERVAL 


END  PERIOD 


ESTIMATE 


type  is  (Pearl,  Gompertz,  Linear, 
Log,  Double-Log) 

*  Selection  of  curve  function  to 
utilize  * 

type  is  range  0..100_000 

*  Julian  date  ELEMENT_ENTEY  is 
placed  in  the  data  base  * 

type  is  range  O..100_000 

*  Julian    date    ELEMENT_ENTRY» s 
ELEMENT_VALUE    is   observed    * 

type  is  (Historical, Estimate) 

*  Indicator  of  whether  data  is 
Observed  or  a  DSS  generated 
Estimate  * 

type  is  STRING (1. .80) 

*  Source  of  data  for 
ELEMENT_ENTRY  * 

type  is  digits  7 

*  Value  of  ELEMENT_ENTRY  * 

type  is  range  0..100_000 

*  Julian  date  representation  of 
the  date  of  the  ending  of  an 
interval.  Base  year  is  1900  * 

type  is  range  0..100_000 

*  Julian  date  representation  of 
the  date  of  the  ending  cf 

a  period.  Base  year  is  1900  * 

type  is  digits  7 

*  An  ELEMENT_VALUE  generated  by 
the  DSS  * 
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FACTCB_ID  =   type  is  STRING  ( 1. . 2 1) 

*  Unique  name  of  a  FACTOR  in  the 
format  'F.  XXXXXXXXXX.  TTTTTTTT'  . 
The  'F.'  indicates  it  is  a 
FACTOR_ID,  the  'Xf  is  for  the 
name  within  a  technology,  th€ 
'T1  is  for  the  technology  * 

FACTCB_IMPACT  =   type  is  STRING  (1.21) 

*  The  FACTOR_ID  of  a  FACTOR  which 
has  an  impact  on  the  key 
FACTOR  * 

FACTOR_LIMIT  =   type  is  digits  7 

*  Highest  value  which  an  ELEMENT_ 
VALUE  may  ever  be.  Could  be  a 
null  value  if  there  is  no 
limit  * 

FACTGF_TYPE  =   type  is  (Sub jec tive, Ob jective) 

*  Indicator  of  whether  a  FACTOR 
is  a  subjective  or  objective 
value  * 

FACTCB_WEIGHT  =   type  is  delta  0.1  range  0.0. -1.0 

*  a  subjective  weighting  of  a 
FACTORS  impact  in  a  model  * 

GR0UP_ID  =   type  is  STRING(1. .21) 

*  Unigue  name  of  a  GROUP  in  the 
format  »G. XXXXXXXXXX. TTTTTTTT* . 
The  ,G.f  indicates  it  is  a 
GROUP_ID,  the  »X»  is  for  the 
name  within  a  technology,  the 
fT'  is  for  the  technology  * 
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GROUP  LEVEL 


GROUP  TYFE 


GROUP  WEIGHT 


IMPACT  FACTOR 


INTERVAL 


INTERVAL  NUMBER 


ITERATIONS 


type  is  range  0 . . 1 

*  Indicator  of  which  GROUPS  act 
upon  other  GROUPS.  Low  numbers 
act  on  high  numbers  * 

type  is  (Desirable/Undesirable) 

*  Indicator  of  whether  a  GROUP  is 
a  desirable  value  or  an 
undesirable  value  * 

type  is  delta  0.1  range  0.0. .1.0 

*  a  subjective  weighting  of  a 
GROUPS  impact  in  a  model  * 

type  is  delta  0.1  range  0.0. .1.0 

*  Subjective  value  of  the  impact 
of  one  FACTOR  upon  another  * 

type  is  range  1..100_000 

*  Length  of  each  interval  over 
which  to  average  data  values 
for  forecasting  as  measured  in 
days  * 

type  is  range  1..400 

*  Number  of  intervals  in  the 
WINDOW  defined  by  the  user  * 

type  is  range  1..500 

*  Number  of  types  to  execute 
Monte  Carlo  simulation  * 
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LAST_INTERVAL_NUV  ER     =   type  is  range  1 . . 400 

*  Last  INTERVAL_NUMBER  in  WINDOW 
defined  by  the  user  * 

LAST_CESERVED_INTEP.VAI   =   type  is  range  1..400 

*  Last  interval  which  contains 
data  which  is  Historical  * 

LOWER  =   type  is  digits  7 

*  The  lower  value  of  the 
confidence  limit  for  an 
interval  in  regression 
analysis  * 

M0DEL_ID  =   type  is  STRING ( 1. . 21) 

*  Unique  name  of  a 
MODEL_STRUCTURE  in  the 

format  • M. XXXXXXXXXX. TTTTTTTT' . 
The  'M.'  indicates  it  is  a 
M0DEL_ID,  the  'X1  is  for  the 
name  within  a  technology,  the 
'  T1  is  for  the  technology  * 

M2  =   type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 

OBSERVED  =   type  is  range  0..1000 

*  Number    of    ELEMENT_VALUES    in    an 
INTERVAL    * 

OUTSIDE_WORLD  =   type  is  delta  0.1  range  0.0. .1.0 

*  Subjective  impact  of  world  upon 
a  FACTOR  * 

03  =   type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 
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RELATIVE  TIME 


STANDAFD  ERROR 


SUB  GROUP  ID 


SUB  GROUP  WEIGHT 


S1 


UNITS 


type  is  range  0..1000 

*  An  counter  of  relative  time 
periods  in  the  Cross  Impact 
Analysis  * 

type  is  digits  7 

*  The  standard  error  of  the 
estimate  of  the  dependent 
variable  in  the  regression 
analysis  * 

type  is  STRING (1. .21) 

*  Unique  name  of  a  SUB_GROUP  in 
format  »S. XXXXXXXXXX. TTITTTTT' 
The  *S.'  indicates  it  is  a 
SUB_GROUP_ID,  the  »X«  is  fcr 
name  within  a  technology,  the 

* T'  is  for  the  technology  * 

type  is  delta  0.1  range  0.0. .1.0 

*  a  subjective  weighting  cf  a 
SUB_GROUPs  impact  in  a  model  * 

type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 

type  is  STRING  (1. .20) 

*  Units  of  measure  for 
ELEMENT  VALUES  * 
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UPPER  =   type  is  digits  7 

*  The  upper  value  of  the 
confidence  limit  for  an 
interval  in  regression 
analysis  * 

VALIDATION  =   type  is  (Valid, Not-Valid) 

*  Indicator  of  whether  a 
USER_SE1ECT  is  acceptable  * 

VARIATE  =   type  is  delta  0.001 

range  0.000. . 1. 000 

*  Value  to  determine  the 
confidence  interval  in 
analysis  * 
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